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Preface 


This  effort  was  initiated  under  a  DARPA/ITO  Broad  Agency  Announcement  #99-07  in  the  topic 
area  of  Trusted  Computing  under  a  Information  Technology  Expedition  search.  The  proposal, 
named  “Trustworthy  Software:  When  Computers  Serve  as  Proxies  for  Humans”  was  initially 
funded  under  the  Software  Enabled  Control  (SEC)  program  as  contract  F33615-99-C-1511  in 
September  1999.  Funding  was  moved  to  the  Program  Composition  for  Embedded  Systems 
(PCES)  program  in  FY2000.  The  contract  was  terminated  in  August  2000  when  it  became 
apparent  that  the  products  were  incompatible  with  the  PCES  efforts.  Insufficient  progress  was 
accomplished  to  generate  a  complete  final  report,  so  a  summary  of  work  attempted  referenced  to 
the  Statement  of  Work  is  being  published  as  the  final  report  along  with  it’s  ITO  Program 
Summary  for  FY2000.  The  appendix  contains  five  papers  published  by  OGI  faculty  and  students 
related  to  this  effort. 
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Trustworthy  Software: 

When  Computers  Serve  as  Proxies  for  Humans 

Final  Project  Report 

September  28,  1999  through  August  21,  2000 

Jan  15,  2001 

AFRL/IFSC 
Attn:  Ron  Szkody 
2241  Avionics  Circle 
WPAFB,  OH  45433-7318 

Re:  Contract  Number  F33615-99-C-1511 

Dear  Mr.  Szkody: 

The  following  is  the  Final  Report  on  ‘Trustworthy  Software:  When  Computers  Serve  as  Proxies 
for  Humans”  concentrating  on  the  period  from  March  31,  2000,  until  the  termination 
of  the  project  on  August  21,  2000. 


Tasks: 


3.1  -  Build  a  reflective  meta-programming  system  for  Haskell.  This  tool  has  two  purposes. 
First,  it  supports  the  construction  of  staged  programs  that  have  good  performance  properties,  and 
second  it  provides  a  high-level  tool  for  the  construction  of  formal  property  analyses  in  the  same 
language  as  the  programming  environment.  This  tool  shall  be  used  to  construct  a  program  along 
the  lines  of  the  HOL-prover  the  contractor  has  built  in  MetaML.  (CDRL  Data  Item  #s  A007 
Software  user  manual,  A008,  software  design  description,  and  A004,  interim  reports) 

Completed: 

•  Designed  a  flexible  datatype  representation  for  Haskell  programs. 

•  Completed  a  parser  that  parses  the  complete  Haskell  Language,  and  produces  an  algebraic 
datatype  that  represents  Haskell  programs. 

•  Completed  design  and  implementation  of  a  flexible  type  checker. 

Not  Completed: 

•  Interfaces  to  Haskell's  class  system  not  implemented. 

•  A007,  Software  user  manual. 

•  A008,  Software  design  description. 

3.2  -  Develop  facets  of  trust.  The  contractor  shall  concentrate  on  exploiting  formal  properties  of 
programs  and  accountability  issues.  Other  facets  shall  be  developed  as  needed.  For  example,  the 
contractor  shall  develop  a  theory  of  accountability  to  formalize  tracking  the  dependency  of 
answers  on  contributed  inputs  and  allow  for  the  delegation  of  accountability.  The  contractor  shall 
also  include  a  notion  of  adaptation.  Whereby  a  system  can  identify  when  a  problem  occurs,  hold 
someone  else  accountable,  then  adapt  by  exploiting  that  accountability.  (CDRL  Data  Item  # 
A004,  interim  reports) 
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Completed: 

•  Developed  analysis  that  guarantee  noninterference  between  processes  that  utilize  separate 
partitions. 

•  Began  investigating  model-based  synthesis  of  trustworthy  software  by  using  Functional 
Reactive  Programming  (FRP)  as  a  model  for  interactive  systems. 

•  Completed  a  design  and  implementation  of  FRP  that  runs  on  top  of  the  Java  Beans  event 
based  model. 

Not  Completed: 

•  Using  Meta-Haskell  tool  to  build  an  automatic  translator  to  do  the  job,  which  was  done  by 
hand  in  the  FRP  implementation  above. 

3.3  -  Apply  the  tools  and  techniques  of  meta-programming,  higher-order  functional 
abstraction,  and  advanced  type  systems  to  represent  and  analyze  facets  of  trust.  This  task  shall 
investigate  the  following  areas: 

3.3.1  -  Develop  encodings  of  important  properties  that  are  directly  checkable  by  an 
extended  Haskell  type  system. 

Completed: 

•  Built  generic  framework  for  building  Hindley-Milner  plus  constraint  type  systems, 
which  can  be  reused  in  many  contexts. 

•  Implemented  a  for  Haskell,  that  was  designed  to  be  extgended. 

•  Devised  a  new  method  for  representing  programs  that  use  the  type  system  of  the 
meta-language  in  a  new  and  unique  way  that  enforces  the  scoping  discipline  of  the 
object  language. 


3.3.2  Exploit  monads  to  track  the  presence  and  absence  of  effects  capabilities 
No  work  on  sub-task  completed. 

3.3.3  Use  an  extended  Hindley-Milner  type  system  such  as  the  HMX  system  to  track  the 
correct  use  of  physical  “units”  or  other  domain-specific  properties  of  interest. 

No  work  on  sub-task  completed. 

3.3.4  Build  an  HOL-like  theorem  prover  to  track  various  levels  of  ‘correctness’,  some  of 
which  might  be  applicable  only  to  specific  domains  of  interest,  for  example,  termination. 

No  work  on  sub-task  completed. 

3.4  -  Build  a  prototype,  which  demonstrates  the  technology  within  a  concrete  scenario.  The 

scenario  shall  be  both  realistic  and  well  developed  within  a  rich  domain  of  interest  such  as 
robotics  or  multi-sensor  control  systems.  The  contractor  shall  demonstrate  the  synthesis  of 
trustworthy  behaviors  in  the  presence  of  untrustworthy  information.  The  system  shall  include 
multiple  sensors  and  agents  of  varying  trustworthiness.  The  contractor  shall  also  use  meta¬ 
programming  and  dynamic  functions  to  modify  system  functionality  in  a  trustworthy  manner  as 
the  system  is  running.  (CDRL  Data  Item  #s  A007  Software  user  manual,  A008,  software  design 
description,  and  A004,  interim  reports) 


2 


Completed: 

•  Developed  a  model  for  interactive  systems  based  on  Functional  Reactive  Programming. 

•  Implemented  parallel  interactive  systems  using  Haskell  systems  communicating  via  the  Linda 
shared  virtual  memory. 

•  Developed  a  method  for  creating  Java  programs  (using  Java  Beans)  from  FRP-based  models. 
Not  Completed: 

•  Demonstration  within  a  concrete  scenario. 

•  A007,  Software  user  manual. 

•  A008,  Software  design  description. 
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Verify  a  Technical  Report 

Attention:  Your  report  has  not  been  accepted  yet! 

Please  review  your  report  for  accuracy,  grammar  and  spelling 
errors.  If  you  are  satisfied  with  your  report  then  click  the 
"Submit”  button  at  the  bottom  of  this  page.  If  you  wish  to  make 
changes  to  your  report  then  click  the  "Back"  button  on  your 
browser. 
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Project  URL: 

http://www.cse.oei.edu/pacsoft/proiects/TW/Default.htm 

Objective: 

To  build  and  demonstrate  a  set  of  modern  tools  to  ensure  that  tomorrow’s 
software  meets  standards  of  trustworthiness  and  reliability. 

Approach: 

Trust  is  an  informal  idea  that  is  part  of  a  complicated  metaphor.  Trust  is 
built,  at  some  level,  on  faith.  No  one  can  completely  trust  any  entity;  yet 
(some)  people  make  reliable  decisions  about  who  and  what  they  can  trust 
everyday.  Surely  software  can  do  the  same.  A  useful  approach  to  the 
construction  of  trustworthy  software  is  in  part  based  upon  the  the 
following  observation:  Trust  depends  on  Understanding. 

•  Use  a  succinct  and  precise  definition  of  a  complex  system  to 
achieve  trust. 

•  A  model  describes  a  complete  system,  encompassing  all  elements 
(components  or  processes)  at  once. 

•  Different  models  focus  on  different  facets  of  trust. 

Models.  A  model  captures  the  meaning  (semantics)  of  a  system  in  a 
declarative  and  composable  way.  The  modeling  language  should 
represent  the  system  in  a  way  that  promotes  human  understanding.  An 
important  way  to  accomplish  this  is  to  use  the  language  of  the  underlying 
domain  embedded  in  a  domain  specific  language.  This  allows  the 
inheritance  of  methods  of  formal  analysis  from  existing  known  domains. 

] 

Strategies.  We  have  used  the  following  strategies  to  build  reliable, 
trustworthy  systems: 

•  Modeling.  Trust  by  understanding.  An  abstraction  prevents  the 
implementation  details  from  getting  in  the  way  of  what  it  does,  but 
provides  a  clean  model  to  the  user  of  how  it  behaves.  When  a 
component  has  an  internal  model  of  its  interaction  with  other 
components  it  can  use  this  model  to  make  informed  decisions  on 
what  and  how  to  trust. 

•  Composition.  Large  systems  can  only  be  built  in  an  effective 
manner  by  composing  them  from  smaller  understood 
sub-components.  Compositionality  is  the  key  to  scaling.  The 
meaning  of  a  component  must  depend  only  on  the  meaning  of  its 
sub-components  to  minimize  unintended  component  interaction. 
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Recent  Accomplishments: 


The  use  of  higher-order  languages  makes  compositionality 
possible. 

•  Factoring.  Separating  concerns  of  functionality  from  concerns  of  j 
accountability  and  trust.  By  using  lifting  operators  that  apply  trust  | 
policies  to  functional  components,  trust  is  achieved  in  an 
orthogonal  way  from  functionality. 

•  Generation.  Trust  is  Ensured  by  the  generation  of  components 
from  abstract  models  where  correctness  is  by  observation.  To 
separate  functional  concerns  from  concerns  of  trust,  a  "weaving"  of  j 
separate  specifications  is  necessary.  This  weaving  is  complex,  and  [ 
usually  beyond  the  capability  of  humans  to  perform  on  large 
systems.  Generation  technology  provides  the  tool  to  accomplish 
this.  Generation  technology  can  be  made  generic,  and  can  be 
reused  over  the  life  of  many  systems.  The  generator  must 
implement  a  faithful  translation.  In  order  to  ensure  that  all 
properties  of  the  model  are  maintained,  It  is  necessary  to  reason 
about  the  generated  code,  only  by  inspecting  the  code  of  the 
generator.  Models  of  how  generators  work  are  a  necessary  part  of 
trustworthy  systems. 

•  Meta-Programming  semantics  and  implementation.  We  have 
implemented  and  released  (March  2000)  MetaML,  a  higher-order, 
typed  programming  languages  that  provides  special  support  for  the 
construction,  manipulation,  and  execution  of  code.  The  release  of 
the  MetaML  system  can  be  found  on  the  project  web  pages. 

Meta-programming  systems  provide  a  common,  reusable  solution 
to  a  number  difficult  problems  that  all  program  generators 
implementations  must  provide.  For  a  brief  overview  of  the  issues 
involved  see  our  Taxonomy  of  Meta-Programming  Systems 
manifesto. 

•  FRP  Semantics.  We  have  developed  a  precise  semantic  model  for 
FRP.  And  continues  to  investigate  the  core  set  of  FRP  constructs. 
Such  a  core  provides  a  reference  implementation  of  FRP  for  other 
researchers.  This  work  is  detailed  in  the  paper: 

Functional  Reactive  Programming  from  First  Principles,  Zhanyong 
Wan  and  Paul  Hudak  .  ACM  SIGPLAN  ’00  Conference  on 
Programming  Language  Design  and  Implementation  (PLDI),  June 
2000,  ACM  Press. 

•  Representing  Object  Programs.  Programs  are  are  data.  But  they 
are  complex  entities.  How  can  programs  be  represented  in  way  that 
hides  unnecessary  details,  but  make  their  important  details  easy  to 
manipulate.  We  have  developed  a  new  method  for  representing 
programs  with  binding  constructs.  It  is  reported  in  the  following 
paper: 

DALI:  An  Untyped,  CBV  Functional  Language  Supporting 
First-Order  Datatypes  with  Binders.  Tim  Sheard,  Walid  Taha  and 
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Emir  Pasalic.  j 

•  Modular  Type  Systems.  We  have  developed  a  mechanism  for 
constructing  type  systems  from  modular  components.  The  ideas  are] 
developed  in  the  following  paper:  Constructing  Modular  Type 
Systems.  Chiyan  Chen. 

•  The  MetaHaskell  System.  We  have  been  constructing 
MetaHaskell,  a  lazy  meta-programming  system  for  the  Haskell 
language.  Our  progress  to  data  includes  a  full  parser,  a  generic  type  j 
checker,  a  generic  type  checking  monad  (which  include  reusable 
components  for  generic  unification,  tracking  errors  to  point  of 
cause,  failure  recovery  and  backtracking).  Our  progress  to  date  can  : 
be  found  on  the  project  web  pages. 

•  Meta-programming:  Restructuring  parallel  programs  to 
increase  throughput.  Parallel  Functional  Reactive  Programming,  i 
by  J.  Peterson,  V.  Trifonov,  and  A.  Seijantov.  Practical  Aspects  of  | 
Declarative  Languages.  (Jan.  17-18,  2000,  Boston  Massachusetts),  j 

•  Efficient  Compilation  of  FRP  programs.  We  have  investigated 
FRP  as  a  way  of  expressing  interaction  in  Java.  This  Integration 
allows  existing  Java  components  to  interact  with  the  FRP 
framework  and  support  composition  of  these  Java  objects.  This 
system  is  currently  restricted  to  first-order  FRP  (no  dynamic 
behavior  creation).  This  work  is  described  in  the  paper:  "Frappe: 
Functional  Reactive  Programming  in  Java"  by  Antony  Courtney. 

Current  Plan:  Modelling  Interaction:  We  have  used  Functional  Reactive 

Programming  (FRP)  to  model  interactive  systems.  Examples  we  have 
built  include  control  systems,  vision,  robotics,  and  reactive  animation. 

FRP  is  a  general  framework  for  adding  interaction  and  time  dependent 
|  behavior  in  a  modular  and  compos  able  way. 

Research  Areas  Addressed  in  FRP: 

•  Essential  FRP  semantics.  We  have  defined  the  meaning  of 
interactive  systems  using  FRP  by  giving  FRP  a  precise 
denotational  semantics.  We  have  also  showed  how  to  reason  and 

I  compare  an  actual  implementation  to  its  denotation. 

•  Analysis  of  FRP-based  systems.  We  have  adapted  existing 
analysis  tools  to  handle  interaction.  We  have  used  FRP  to  construct ! 
models  in  specific  domains.  For  example,  web  servers,  and  robot 
control  systems. 

•  Compilation  techniques  for  FRP-based  systems.  We  have 
realized  FRP-based  systems  practically  and  reliably  using 
higher-order  programming  languages,  program  generation  and 
meta-programming. 

i  Meta-programming:  Generating  Solutions.  We  have  used 
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meta-programming  as  a  generic  tool  for  generating  solutions  and 
verifying  properties  from  high-level  specifications.  Example  generated 
solutions  include:  compilers  for  DSLs  and  staged  pattern  matching. 
Example  properties  include  extended  type  systems,  and  generic  property 
maintenance  and  propagation.  We  have  found  meta-programming  to  be  a 
generic  framework  for  manipulating  programs  in  a  high-level  and 
semantically  coherent  way. 

Research  Areas  Addressed  in  Generation. 

•  Semantics.  We  have  devised  the  first  useful  logic  that  can  be  used 
to  compare  whether  two  meta-programs  compute  the  same  thing. 
The  logic  can  also  be  used  to  compare  the  equivalence  of  a 
program  and  its  staged  counterpart. 

•  Type  Systems.  We  have  devised  and  implemented  a  type  system 
for  the  meta-language  MetaML  that  ensures  safety  properties  of 
generated  programs  by  typing  the  meta-programs  themselves. 

•  Representing  Programs.  Programs  are  are  data.  But  they  are 
complex  entities.  We  have  devised  a  new  method  for  representing 
programs  in  way  that  hides  unnecessary  details  (such  as  the  actual 
names  of  local  variables)  but  make  their  important  details  easy  to 
manipulate. 

•  Modular  Composition.  We  have  structured  language 
implementations  in  a  way  that  is  easy  to  reuse  by  applying  the  the 
technologies  of  monads  and  staging.  This  makes  it  easier  to  build 
and  prototype  new  language  systems  rapidly. 


Technology  Transition: 

By  making  our  systems  public,  we  have  encouraged  other  groups  to  use 
them  as  tools  in  their  own  work.  The  MetaML  system  has  been  publicly 
available  since  March  2000. 
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2000),  and  Postdoc,  Bill  Harrison,  OGI  (just  starting  June  7,  2000). 
Students  Chiyan  Chen,  OGI,  Antony  Courtney,  Yale,  and  Zhanyong 

Wan,  Yale. 
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Functional  Reactive  Programming  from  First  Principles 


Zhanyong  Wan 

Yale  University 

Department  of  Computer  Science 
P.O.  Box  208285 
New  Haven,  Connecticut  06520 

zhanyong.wan@yale.edu 


ABSTRACT 

Functional  Reactive  Programming ,  or  FRP ,  is  a  general  frame¬ 
work  for  programming  hybrid  systems  in  a  high-level,  declar¬ 
ative  manner.  The  key  ideas  in  FRP  are  its  notions  of  be¬ 
haviors  and  events.  Behaviors  are  time- varying,  reactive  val¬ 
ues,  while  events  are  time-ordered  sequences  of  discrete-time 
event  occurrences.  FRP  is  the  essence  of  Fran ,  a  domain- 
specific  language  embedded  in  Haskell  for  programming  re¬ 
active  animations,  but  FRP  is  now  also  being  used  in  vision, 
robotics  and  other  control  systems  applications. 

In  this  paper  we  explore  the  formal  semantics  of  FRP  and 
how  it  relates  to  an  implementation  based  on  streams  that 
represent  (and  therefore  only  approximate)  continuous  be¬ 
haviors.  We  show  that,  in  the  limit  as  the  sampling  interval 
goes  to  zero,  the  implementation  is  faithful  to  the  formal, 
continuous  semantics,  but  only  when  certain  constraints  on 
behaviors  are  observed.  We  explore  the  nature  of  these  con¬ 
straints,  which  vary  amongst  the  FRP  primitives.  Our  re¬ 
sults  show  both  the  power  and  limitations  of  this  approach 
to  language  design  and  implementation.  As  an  example  of 
a  limitation,  we  show  that  streams  are  incapable  of  repre¬ 
senting  instantaneous  predicate  events  over  behaviors. 

L  INTRODUCTION 

How  does  one  show  that  a  language  implementation  is  cor¬ 
rect?  In  the  programming  language  research  community, 
we  normally  do  this  by  showing  that  the  implementation  is 
faithful,  in  some  formal  sense,  to  an  abstract  denotational 
or  operational  semantics  of  the  language.  Indeed,  if  all  goes 
well,  we  can  formally  derive  the  implementation  from  the 
semantics.  Such  is  the  nature  of  “provably  correct  compila¬ 
tion.” 

However,  in  the  case  of  Functional  Reactive  Progamming 
(FRP),  a  novel  language  involving  continuous  time- varying 
values  as  well  as  discrete  events,  the  situation  is  not  as  clear, 
and  several  questions  arise: 
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1.  How  does  one  express  the  formal  semantics  of  FRP? 
We  partially  answered  this  question  in  a  previous  pa¬ 
per  [7],  and  we  refine  that  strategy  here. 

2.  How  does  one  implement  continuous  time-varying  be¬ 
haviors?  In  this  paper  we  explore  perhaps  the  most 
obvious  technique,  one  based  on  streams  that  repre¬ 
sent  sampled  behaviors  (in  a  signal  processing  sense). 
However,  this  representation  is  only  an  approximation 
to  the  continuous  values,  which  leads  to  the  next  ques¬ 
tion. 

3.  In  what  sense  is  an  approximating  stream-based  im¬ 
plementation  correct  with  respect  to  the  formal  se¬ 
mantics,  and  what  are  its  limitations  (for  example,  are 
there  values  that  cannot  be  represented)?  The  inter¬ 
action  of  these  issues  with  the  reactive  component  of 
FRP  makes  this  especially  interesting. 

In  this  paper  we  provide  answers  to  all  of  these  questions. 
Specifically,  we  give  a  denotational  semantics  to  FRP,  and 
show  that  in  the  limit  as  the  sampling  interval  goes  to  zero, 
a  stream-based  implementation  corresponds  precisely  to  the 
formal  semantics,  but  only  with  suitable  constraints  on  the 
nature  of  behaviors.  The  good  news  here  is  that  most  of  the 
common  things  that  we  express  with  FRP  programs  are  well 
behaved,  and  laws  that  we  expect  to  hold  in  mathematics  are 
justified,  in  the  limit,  when  reasoning  about  FRP  programs. 
For  example,  we  can  safely  apply  most  FRP  primitives,  such 
as  integration,  to  behaviors  that  are  discontinuous  (in  a  cer¬ 
tain  way  to  be  described  later),  which  is  critically  important 
given  that  the  reactive  component  of  FRP  creates  disconti¬ 
nuities  quite  often. 

The  bad  news  is  that,  since  FRP  is  mathematically  very 
rich,  many  ill  behaved  values  can  be  expressed.  As  a  result, 
an  FRP  term  does  not  always  have  a  meaningful  seman¬ 
tics.  In  such  cases  we  say  that  the  term  denotes  _L  (and 
is  thus  denotationally  equivalent  to  non-termination  or  er¬ 
ror).  Of  course,  this  is  not  very  informative.  Even  worse, 
it  is  possible  to  write  egregious  behaviors  for  which  either 
the  implementation  does  not  converge  when  we  increase  the 
sampling  rate,  or  it  converges  to  something  other  than  its 
semantics.  However,  we  are  able  to  identify  a  set  of  sufficient 
conditions  which  guarantees  the  fidelity  of  the  implementa¬ 
tion.  These  conditions  are  neither  complete  nor  decidable 
in  general,  which  means  the  burden  of  “good  behavior”  is 
on  the  programmer.  However,  it  is  perhaps  not  surprising 
given  such  a  rich  mathematical  language. 
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2.  AN  INTRODUCTION  TO  FRP 

In  this  section  we  give  a  very  brief  introduction  to  FRP;  see 
[5,  7]  for  more  details,  FRP  is  an  example  of  an  embed¬ 
ded  domain- specific  language  [9].  In  our  case  the  “host”  is 
Haskell  [11],  a  higher-order,  typed,  polymorphic,  lazy  and 
purely  functional  language,  and  thus  all  of  our  examples  (as 
well  as  our  implementation)  are  in  Haskell  syntax. 

There  are  two  key  polymorphic  data  types  in  FRP:  the 
Behavior  and  the  Event.  A  value  of  type  Behavior  a  is 
a  value  of  type  a  that  varies  over  continuous  time.  Con¬ 
stant  behaviors  include  numbers  (such  as  1  :  :  Behavior 
Real),  colors  (such  as  red  :  :  Behavior  Color),  and  oth¬ 
ers.  The  most  basic  time-varying  behavior  is  time  itself: 
time  :  :  Behavior  Time,  where  Time  is  a  synonym  for  Real. 
More  interesting  time-varying  behaviors  include  animations 
of  type  Behavior  Picture  (which  is  the  key  idea  behind 
Fran  [5,  7],  a  language  for  functional  reactive  animations), 
sonar  readings  of  type  Behavior  Sonar,  velocity  vectors  of 
type  Behavior  (Real, Real),  and  so  on  (the  latter  two  ex¬ 
amples  are  used  in  Frob  [13,  14],  an  FRP-based  language  for 
controlling  robots).  (Note:  In  our  implementation  the  type 
Real  is  approximated  by  Float.) 

A  value  of  type  Event  a  is  a  time-ordered  sequence  of  event 
occurrences,  each  carrying  a  value  of  type  a.  Basic  events  in¬ 
clude  left  button  presses  and  keyboard  presses,  represented 
by  the  values  lbp  : :  Event  0  and  key  : :  Event  Char, 
respectively.  The  declarative  reading  of  lbp  (and  key)  is 
that  it  is  an  event  sequence  containing  all  of  the  left  button 
presses  (and  key  presses),  not  just  one. 

Behaviors  and  events  are  both  first-class  values  in  FRP,  and 
there  is  a  rich  set  of  operators  (combinators)  that  the  user 
can  use  to  compose  new  behaviors  and  events  from  existing 
ones.  An  FRP  program  is  just  a  set  of  mutually-recursive 
behaviors  and  events,  each  of  them  built  up  from  static  (non¬ 
time-varying)  values  and/or  other  behaviors  and  events. 

Suppose  that  we  wish  to  generate  a  color  behavior  which 
starts  out  as  red,  and  changes  to  blue  when  the  left  mouse 
button  is  pressed.  In  FRP  we  would  write: 

>  color  : :  Behavior  Color 

>  color  =  red  ‘until*  (lbp  -=>  blue) 

This  can  be  read  “behave  as  red  until  the  left  button  is 
pressed,  then  change  to  blue.”  We  can  then  use  color  to 
color  an  animation,  as  follows: 

>  ball  : :  Behavior  Picture 

>  ball  =  paint  color  circ 

> 

>  circ  : :  Behavior  Region 

>  circ  =  translate  (cos  time,  sin  time)  (circle  1) 

Here  circle  1  creates  a  circle  with  radius  1,  and  the  trans¬ 
lation  causes  it  to  revolve  about  the  center  of  the  screen 
with  period  2rr  seconds.  Thus  ball  is  a  revolving  circle 
that  changes  from  red  to  blue  when  the  left  mouse  button 
is  pressed. 


Sometimes  it  is  desirable  to  choose  between  two  different 
behaviors  based  on  user  input.  For  example,  this  version  of 
color: 

>  color2  =  red  ‘until* 

>  (lbp  -=>  blue)  . | .  (key  -=>  yellow) 

will  start  off  as  red  and  change  to  blue  if  the  left  mouse 
button  is  pressed,  or  to  yellow  if  a  key  is  pressed.  The  .  I  . 
operator  can  be  read  as  the  “or”  of  its  event  arguments. 

The  function  when  transforms  a  Boolean  behavior  into  an 
event  that  occurs  exactly  “when”  the  Boolean  behavior  be¬ 
comes  True;  this  is  called  a  predicate  event.  For  example: 

>  color3  =  red  ‘until* 

>  (when  (time  >*  5)  -=>  blue) 

defines  a  color  that  starts  off  as  red  and  becomes  blue  after 
time  is  greater  than  5. 

Sometimes  it  is  desirable  to  “lift”  an  ordinary  value  or  func¬ 
tion  to  an  analogous  behavior.  The  family  of  functions 

>  liftO  : :  a  ->  Behavior  a 

>  liftl  : :  (a  ->  b)  ->  (Behavior  a  ->  Behavior  b) 

and  so  on,  perform  such  coercions  in  FRP.  Sometimes  Haskell 
overloading  permits  us  to  use  the  same  name  for  lifted  and 
unlifted  functions,  such  as  most  of  the  arithmetic  operators. 
When  this  is  not  possible,  we  use  the  convention  of  placing 
a  after  the  unlifted  function  name.  For  example,  >*  in 
the  col  or  3  example  is  the  lifted  version  of  >. 

Finally,  one  of  the  most  useful  operations  in  FRP  is  inte¬ 
gration  of  numeric  behaviors  over  time.  For  example,  the 
physical  equations  that  describe  the  position  of  a  mass  un¬ 
der  the  influence  of  an  accelerating  force  f  can  be  written 
as: 

>  s,v  ::  Behavior  Real 

>  s  =  sO  +  integral  v 

>  v  =  vO  +  integral  f 

where  sO  and  vO  are  the  initial  position  and  velocity,  respec¬ 
tively.  Note  the  similarity  of  these  equations  to  the  mathe¬ 
matical  equations  describing  the  same  physical  system: 

s{t)  =  So  +  /o  v(t)  dr 
v(t)  =  vo  +  fg  f(r)  dr 

This  example  demonstrates  well  the  declarative  nature  of 
FRP.  A  major  design  goal  for  FRP  is  to  free  the  program¬ 
mer  from  “presentation”  details  by  providing  the  ability  to 
think  in  terms  of  “modeling.”  It  is  common  that  an  FRP 
program  is  concise  enough  to  also  serve  as  a  specification  for 
the  problem  it  solves. 

There  are  many  other  useful  operations  in  FRP,  but  we  in¬ 
troduce  them  only  as  needed  in  the  remainder  of  the  paper. 
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3.  THE  SEMANTIC  FRAMEWORK 

In  this  section  we  present  the  semantic  framework  for  be¬ 
haviors  and  events.  The  semantics  of  each  FRP  construct 
will  be  given  individually  in  Section  6. 

FRP’s  notion  of  continuous  time  is  denoted  by  the  domain 
Time,  which  is  a  synonym  for  the  set  of  real  numbers  K.  Let 
(Behavior^)  and  (Events)  denote  the  set  of  all  FRP  terms  of 
type  Behavior  a  and  Event  a  respectively,  where  a  is  any 
Haskell  data  type.  The  meaning  of  behaviors  and  events  is 
given  by  the  following  semantic  functions: 

at  :  (Behavior*)  -¥  Time  Time  — >  a 

occ  :  (Event*)  — »  Time  — >  Time  -*  [Time  x  a] 

where  [— ]  is  the  list  type  constructor. 

Intuitively,  the  meaning  of  a  behavior,  as  given  by  at,  is  a 
function  mapping  a  start  time  and  a  time  of  interest  to  the 
value  of  the  behavior  at  the  given  time  of  interest.  Start 
times  relate  to  the  reactive  nature  of  FRP.  For  example, 
in  ( b  ‘  until f  e),  if  an  event  occurrence  (t,bf)  of  e  causes 
the  overall  behavior  to  switch  to  b\  we  say  that  b'  starts  at 
time  t.  A  behavior  is  unaware  of  any  event  occurrences  that 
happened  before  its  start  time. 

The  meaning  of  an  event,  given  by  occ,  is  a  function  that 
takes  also  a  start  time  T  and  a  time  of  interest  i,  and  returns 
a  finite  list  of  time-ascending  occurrences  of  the  event  in  the 
interval  (T,  t].  The  start  time  of  an  event  is  analogous  to 
the  start  time  of  a  behavior.  Note  that  the  lower  end  of  the 
interval  is  open,  which  means  an  occurrence  precisely  at  the 
start  time  is  not  detected. 

Note  that,  for  simplicity,  we  have  omitted  real-world  events 
such  as  user  input  and  general  I/O  from  this  semantic  frame¬ 
work.  However,  predicate  events  such  as  described  in  the 
last  section  are  still  present,  which  are  sufficient  to  demon¬ 
strate  all  interesting  aspects  of  the  semantics  and  implemen¬ 
tation.  Nevertheless,  for  completeness,  we  describe  how  to 
add  user  input  in  Section  8. 

4.  A  STREAM  IMPLEMENTATION  OF  FRP 

Our  stream-based  implementation  of  FRP  is  interesting  in 
its  own  right,  but  because  of  space  limitations  we  omit  a 
detailed  discussion  of  it  here;  the  basic  idea  is  outlined  in  [6] 
and  elaborated  in  [10]. 

The  core  data  types  in  FRP,  Behavior  and  Event,  are  given 
by: 

>  type  Behavior  a  =  [Time]  ->  [a] 

>  type  Event  a  =  [Time]  ->  [Maybe  a] 

Here  Maybe  a  is  a  data  type  whose  values  are  either  Nothing 
or  Just  rc,  where  x  is  some  a. 

Intuitively,  a  behavior  is  a  stream  transformer:  a  function 
that  takes  an  infinite  stream  of  sample  times,  and  yields  an 
infinite  stream  of  values  representing  its  behavior.  Similarly, 
an  event  is  also  a  stream  transformer,  and  can  be  thought 
of  as  a  behavior  where,  at  each  time  i,  the  event  either 


occurs  (indicated  as  Just  x  for  some  r),  or  does  not  occur 
(indicated  as  Nothing).  Note  that  using  this  implementation 
strategy  for  events  means  that  we  must  ensure  that  the  time 
associated  with  each  event  occurrence  actually  appears  in 
the  time  stream,  but  this  is  easily  done. 

The  implementation  itself  can  be  divided  into  two  parts:  (1) 
definitions  of  FRP’s  primitive  behaviors,  events,  and  combi- 
nators  as  stream  transformers,  and  (2)  a  “run-time  system” 
that  interprets  the  behaviors  and  events  by  building  an  infi¬ 
nite  stream  of  sample  times  and  applying  the  behavior/event 
to  the  stream.  The  latter  task  is  explained  in  the  remainder 
of  this  section;  we  return  to  the  former  in  Section  6. 

To  simplify  the  presentation  of  the  run-time  system,  we  omit 
the  interface  to  the  operating  system  that  extracts  events, 
grabs  the  clock  time,  etc.  The  resulting  abstract  implemen¬ 
tation  is  captured  by  the  following  pair  of  “interpreters,” 
one  for  behaviors,  the  other  for  events: 

at  :  (Behavior*)  — >  [Time]  — »  a 
H  pf 

at[b ]  ts  =  last  (|_6J  ts) 

occ  :  (Event*)  ->  [Time]  — >  [Time  x  a] 

.  def 

occ[e]  ts  =  justValues  ts  ([ej  ts) 

where  (1)  we  write  [-J  for  the  value  (which  could  be  a 
function)  denoted  by  the  Haskell  term  — ,  (2)  last  returns 
the  last  element  of  a  list,  and  (3)  the  auxiliary  function: 

justValues  :  [Time]  — >  [Maybea]  — y  [Time  x  a] 

time-stamps  a  stream  of  “Maybe”  values  while  dropping  the 
“Nothing’s.”  For  example, 

justValues  [0.0,  0.1,  0.2,  0.3,  0.4] 

[Nothing, Just  False, Nothing, Nothing, Just  True] 

returns  [(0.1,  False),  (0.4,  True)]. 

Intuitively,  at  takes  a  behavior  and  an  ordered  finite  list  of 
sample  Time’s,  the  first  in  the  list  being  the  start  time  of  the 
behavior  and  the  last  being  the  time  of  interest.  It  returns 
as  result  the  value  of  the  behavior  at  the  time  of  interest. 
Similar  is  occ,  which  returns  all  the  occurences  detected 
up  until  the  time  of  interest.  In  essence,  at  and  occ  define 
an  operational  semantics  for  FRP.  (Note  that  b  is  a  Haskell 
term  of  type  [Time]  ->  [a] ,  so  |_6J  is  a  function  of  type 
[Time]  ->  [a],  and  therefore  [b\  ts  is  a  value  of  type  [a].) 

In  this  paper  we  are  most  interested  in  the  limit  of  the  op¬ 
erational  semantics  as  the  sampling  interval  goes  to  zero. 
Thus  we  define: 

at*  :  (Behaviora)  — >■  Time  -»  Time  -*•  a 

def  flimi  i_,n  o.t{b}  such  limit  exists 

at{b\Tt={  I'VH0  1  “ 

[_L  otherwise 

occ *  :  (Events)  — >  Time  Time  — >  [Time  x  a] 

„  def  |  n  occfe]  P £  such  limit  exists 

occ  [ej  T  t  =  <{  \pt\^° 

[_L  otherwise 

where  P £  is  a  partition  of  [T,  t] . 
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Definition  1.  (Partition  and  norm  of  partition)  A  parti¬ 
tion  P  of  a  closed  interval  [a, b)  is  a  non-empty  finite  list 
[xo,xi, . . .  ,xn],  such  that  a  =  xo  <  x\  <  •••  <  xn  =  6, 
where  n  >  0.  Such  a  partition  is  often  written  as  P%.  The 
norm  of  P,  written  as  |P|,  is  defined  as  the  maximum  of  the 
set  {xi  —  Xi~  i  |  1  <  i  <  n}  when  n  >  1,  or  0  when  n  =  0. 

(Note  that  we  overload  the  notation  [a,  b]  for  both  a  closed 
interval  and  a  list  of  two  elements,  and  similarly  (a,  b)  for 
both  an  open  interval  and  a  tuple.  However,  the  meaning  is 
always  clear  from  context.) 

5.  FAITHFUL  IMPLEMENTATIONS  AND 
UNIFORM  CONVERGENCE 

In  the  next  section  we  will  give  both  the  denotational  se¬ 
mantics  and  stream-based  implementation  of  each  FRP  con¬ 
struct  in  turn,  and  show  in  each  case  that  the  implementa¬ 
tion  is  faithful  to  the  semantics,  though  possibly  only  under 
certain  constraints,  in  the  following  formal  sense: 

at*[b]  T  t  =  at [b]Tt  (1) 

occ*[e]  T  t  =  occ[e]  T  t 

In  addition,  we  will  identify  the  cases  where  the  implemen¬ 
tation  converges  uniformly ,  a  property  (defined  below)  that 
is  necessary  to  ensure  that  the  integral  of  a  numeric  behavior 
is  well  defined.  Analogous  to  the  concept  of  uniform  conver¬ 
gence  for  real  number  function  series  [1,  page  393],  we  define 
uniform  convergence  for  functions  defined  on  partitions  of 
real  intervals: 

Definition  2.  (Uniform  Convergence)  Given  a  set  S',  we 
say  that  a  function  F  defined  on  Pr,  which  is  the  set  of 
all  partitions  whose  left  (i.e.  smaller)  end  is  T,  converges 
uniformly  to  /  on  S  if,  for  every  e  >  0,  there  exists  a  <5  >  0 
(depending  only  on  e)  such  that  for  every  t  €  S  and  P£ 
satisfying  |Pf|  <  5 , 

\F(P±)  ~  f(t)\  <  e 
We  denote  this  symbolically  by  writing 

F(Pt)  ^  /W  uniformly  on  S 

So,  when  possible,  we  will  indicate  when  the  following  con¬ 
dition  holds: 

atfb J  Pt  >-+  at [6]|  T  t  uniformly  (2) 

Note  that  (2)  implies  (1),  and  for  conciseness  we  will  not 
write  out  (1)  if  we  have  already  established  (2). 

Because  FRP  is  an  “embedded”  DSL,  it  is  difficult  to  draw  a 
clear  line  between  FRP  and  Haskell.  Thus  a  full  treatment 
of  the  FRP  “language”  inevitably  requires  a  treatment  of 
all  of  Haskell.  As  this  would  obscure  our  main  interest,  we 
choose  to  discuss  only  the  constructs  specific  to  FRP. 

6.  CORRESPONDANCE  BETWEEN  SEMAN¬ 
TICS  AND  IMPLEMENTATION 

The  proof  of  the  important  theorems  in  this  section  can  be 
found  in  appendix  A. 


Time 

The  primitive  behavior  time  is  implemented  as: 

>  time  : :  Behavior  Time 

>  time  =  \ts  ->  ts 

and  its  semantics  is  given  by: 

at  [time]  T  t  =  t 

We  can  show  that  the  implementation  of  time  is  faithful  to 
its  semantics,  and  that  its  convergence  is  uniform: 

Theorem  1.  atftime]  Pf  >— *■  t  uniformly  on  (—00,00). 

Lifting 

Here  we  show  the  correctness  of  the  three  most  useful  lift¬ 
ing  operators:  liftO,  liftl  and  lift2.  The  result  easily 
extends  to  any  arity  of  lifting.  The  lifting  operators  are 
implemented  as: 

>  ($*)  : :  Behavior  (a  ->  b) 

>  ->  Behavior  a  ->  Behavior  b 

>  ff  $*  fb  = 

>  \ts  ->  zipWith  ($)  (ff  ts)  (fb  ts) 

> 

>  liftO  : :  a  ->  Behavior  a 

>  liftO  x  =  map  (const  x) 

> 

>  liftl  : :  (a  ->  b)  ->  (Behavior  a  ->  Behavior  b) 

>  liftl  f  bl  =  liftO  f  $*  bl 

> 

>  lift2  : :  (a  ->  b  ->  c) 

>  ->  (Behavior  a 

>  ->  Behavior  b  ->  Behavior  c) 

>  lift2  f  bl  b2  =  liftl  f  bl  $*  b2 

The  semantics  of  liftO  is  given  by: 

at  [liftO  c]  T  t  =  [cj 

Unsurprisingly,  the  implementation  converges  to  the  seman¬ 
tics  uniformly: 

Theorem  2.  atpLiftO  c]  P?  >— ►  [c\  uniformly  on 

(-00, 00). 

The  semantics  of  liftl  is  given  by: 

at[liftl  /  6]  T  t  =  [/J  (at [6]  T  t) 

The  implementation  of  liftl  is  faithful  to  its  semantics, 
but  only  when  the  lifted  function  is  continuous: 

Theorem  3.  If  at*  [6]  T  t  =  bt,  and  [f\  is  continuous  at 
bt ,  then  at* [liftl  f  b]  T  t  =  [f\  bt . 

It  is  worth  noting  that  we  only  require  [/J  to  be  continuous 
at  bt,  not  necessarily  continuous  everywhere.  Since  most 
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functions  we  deal  with  in  FRP  are  either  globally  continuous 
or  piecewise  continuous,  the  theorem  applies  in  most  cases. 

To  see  whether  the  convergence  of  lift  1  is  uniform,  we  need 
a  concept  called  uniform  continuitij[  1,  page  74],  as  found  in 
most  treatments  of  calculus: 

Definition  3.  (Uniform  Continuity)  A  function  /  is  said 
to  be  uniformly  continuous  on  a  set  S  if  for  every  e  >  0,  there 
exists  a  5  >  0  (depending  only  on  e)  such  that  if  x,y  €  S 
and  \x  -  y\  <  <5,  then  \  f(x)  -  f(y)\  <  e. 

Theorem  4.  If  a£[6]  P £  >—*  fb(t)  uniformly  on  S,  and 
L/'J  is  uniformly  continuous,  then 

aifliftl  /  6]  Pt  >-*  |_/J  (/&(*))  uniformly  on  S 
For  example,  the  lifted  sin  function  is  defined  as:1 

>  instance  Floating  a  =>  Floating  (Behavior  a)  where 

>  sin  -  liftl  sin 

Note  that  the  sin  on  the  right  hand  side  of  the  definition  is 
the  static  version  as  in  the  standard  Haskell  library: 

>  sin  : :  Floating  a  =>  a  ->  a 

As  an  example,  we  can  use  theorem  4  to  prove  that  the 
expression  “sin  time”  in  FRP  actually  denotes  the  mathe¬ 
matical  notion  of  sin(t),  where  t  is  the  current  time. 

Corollary  1.  atfsin  timej  Pt  >->  sint  uniformly  on 
(—oo,  oo). 

The  semantics  of  lift 2  is  given  by: 

at[lift2  /  b  d]  T  t  =  [/J  (at [6]  T  t)  (at[d]  T  t) 
Similar  to  liftl,  we  can  show: 

Theorem  5.  If  at*{bj  T  t  =  bt,  at*\d\  T  t  =  dt,  and 
(uncurry  [/J)  is  continuous  at  (bt,dt),  then 

a£*[lift2  /  b  d\  T  t  —  [ f\  bt  dt. 

as  well  as  the  following  for  uniform  convergence: 

_  Theorem  6.  If  at{b]  P<f  >-»  fb(t)  uniformly  on  S, 
at[d ]  P<f  >->  fd(t)  uniformly  on  S,  and  ( uncurry  [/J)  is 
uniformly  continuous,  then 

o<[lift2  /  b  d]  Pt  >->  L/J  (/&(*))  ( fd{t )) 

uniformly  on  S. 

1The  instance  declaration  shown  here  is  how,  using  Haskell’s 
type  class  system,  functions  are  overloaded.  In  this  case, 
sin  is  a  method  in  the  class  Floating,  and  the  instance 
declaration  says  that  sin  may  now  be  used  for  values  of 
type  Behavior  a,  for  any  type  a  that  is  already  an  instance 
of  the  class  Floating. 


For  example,  we  can  use  this  theorem  to  verify  the  semantics 
of  the  lifted  binary  operator  +: 

>  instance  Num  a  =>  Num  (Behavior  a)  where 

>  (+)  =  lift2  (+) 

Corollary  2.  at*{b  +  dj  T  t  —  at*  [6]  T  t  -f  at{d ]  T  t 

Integration 

We  use  a  very  simply  numerical  algorithm  to  calculate  the 
Riemann  integration  of  numeric  behaviors: 

>  integral  : :  Behavior  Real  ->  Behavior  Real 

>  integral  fb  = 

>  \ts@(t:tsO  ->  0  :  loop  t  0  ts’  (fb  ts) 

>  where  loop  tO  acc  (tl:ts)  (a:as) 

>  =  let  acc’  ~  acc  +  (tl-tO)*a 

>  in  acc*  :  loop  tl  accJ  evs  ts  as 

The  formal  semantics  of  integral  is  given  by: 

atfintegral  /J  T  t  —  J  (at|/J  T  r)  dr 

As  mentioned  earlier,  this  stream-based  integrator  is  only 
sound  mathematically  if  the  behavior  to  be  integrated  con¬ 
verges  uniformly: 

Theorem  7.  If  at[b]  Pt  >— *  fb(r)  uniformly  on  [T,t], 
then 

a£[integral  6]  Pt  >— »  f  fb(r])  dr] 

Jt 

uniformly  on  [T,t]. 

If  at[ 6}  Pf  ^  /6(r)  non-uniformly ,  we  can  say  nothing 
about  at  [integral  bj  T  t.  As  an  instance,  consider  the 
behavior  bizarre  (inspired  by  [1,  page  401]),  which  is  non- 
uniformly  convergent  on  [0, 1],  and  is  defined  as: 

>  bizarre  : :  Behavior  Real 

>  bizarre  =  0  ‘ until 1  e  ==>  b 

>  where  e  =  when  (time  >*  0)  f snapshot'  time 

>  b  =  \(_>tl)  ->  c*c*time* ( 1  -  time)**c 

>  where  c  =  1/tl 

On  time  interval  [0, 1],  the  above  is  equivalent  to: 

>  bizarre  =  \(t0:tl:ts)  -> 

>  0:0:  map  (let  c  =  l/(tl  -  tO) 

>  in  \t  ->  c*c*t*(l  -  t)**c)  ts 

When  t  E  [0, 1],  we  have 
at  [bizarre]  0  t 

=  lim^ | 0  last  ([bizarrej  Pq) 

=  lim|p^  |_^0  c2£(1  —  t)c ,  where 

1/c  =  the  length  of  the  first  sub-interval  of  Pq 

=  0 
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Hence  [bizarre J  0  ^  dt  =  0.  However,  we  have 

at*  [integral  bizarre]  0  1 
=  lim|P0i|->0Er=i  (LhizarreJ  Po)(i)  *  &U 

where  Pq  =  [to  =  0,  t\ , . . , ,  tn  —  1],  and 
subscript  means  the  i-th  element  of  a  list 
=  -ii-i)c  •  Aii, 

where  c  —  1/Ati 


>  (==>)  : :  Event  a  ->  (a->b)  ->  Event  b 

>  fe  ==>  f  =  map  (map  f)  .  fe 

Its  semantics  is  given  by: 
occ[e  ==>  f\Tt  — 

[(*i,L/J  vL),(t2,lf\  v2),  Wn)],  where 

OCc[e]  T  t  =  (t2,  V2),  ■■■,  (tn,  Vn)\ 


and 

lim  [  c2t(l  —  t)cdt 
c->oo  J0 

Therefore 


lim 

c— >oo 


(c+l)(c  +  2) 


1 


a,t*  [integral  bizarre]  0  1 
^  J  (at*  [bizarre]  0  ^  dt 

In  other  words,  the  limit  of  the  integral  doesn’t  agree  with 
the  integral  of  the  limit  for  bizzare. 


It  turns  out  that  global  uniform  convergence  is  usually  too 
strong  a  condition  to  achieve  in  practice,  part  of  the  reason 
being  that  the  interplay  of  behaviors  and  events  often  re¬ 
sults  in  _L  at  the  point  of  behavior  switching.  The  following 
theorem  relaxes  the  requirement  considerably: 


Theorem  8.  If  at[bj  Pf  >-*  fb{r)  uniformly  on  [T,t], 
except  at  n  (finite)  points  n,  r2,  . ..?  rn,  and  at{b]  Pf1  is 
bounded  as  \  Pf{  |  -»  0  for  every  1  <  i  <  n,  then 

a<[integral  6]  Pf  >— »  J  F(rj)  drj 

uniformly  on  [T,t],  where 

_  f  fH7])  V  #  rifor  everyl  <i  <n 

1  any  finite  value  otherwise 


Since  most  behaviors  we  encounter  in  practice  are  bounded 
on  every  finite  interval,  the  above  condition  is  not  hard  to 
satisfy. 

As  shown  in  theorem  7,  integration  preserves  the  uniform 
convergence  property.  This  allows  us  to  safely  calculate  the 
second  integral,  the  third,  and  so  on: 


Corollary  3.  If  at[b\  Pf  >— ►  fb(r)  uniformly  on  [T,t], 
then 


at[  integral  (integral  ...(integral  &)...)]  Pf 

nr  pti  rrn-i 

>->  /  /  . ../  /6(rn)  drn  drn-i  . . .  dn 

Jt  Jt  Jt 

uniformly  on  [T,t]. 


Event  Mapping 

The  ==>  operator  essentially  maps  a  function  over  the  event 
stream,  and  is  implemented  as: 


Theorem  9.  Ifocc*[e]  T  t  =  [(£i,iu),  (£2,^2), . . . ,  (tn,  vn)], 
and  [/J  is  continuous  at  Vi  for  every  1  <  i  <  n}  then 

occ*  [e  ==>  /]  T  t  = 

[(ill  L/J  «l)>(i2,L/J  V2),...,(tn,  L/J  Hn)] 

The  -=>  operator  we  used  previously  is  just  syntactic  sugar: 
e  -=>  b  ^  e  ==>  \_  ->  b 


Choice 

.  |  .  can  be  used  to  merge  two  events  of  the  same  type;  it  is 
implemented  as: 

>  (.  |  .)  :  :  Event  a  ->  Event  a  ->  Event  a 

>  fel  . I .  fe2  = 

>  \ts  ->  zipWith  aux  (fel  ts)  (fe2  ts) 

>  where  aux  Nothing  Nothing  =  Nothing 

>  aux  (Just  x)  _  =  Just  x 

>  aux  _  (Just  x)  =  Just  x 


The  semantics  of  .  I .  operator  is  given  by: 


If  occ[ei]  T  t  =  [(<i,wi),  (<2>  112)1  •  ■  • ,  (tn,Vn)],  occ[e2]  T  t  - 
[MX),  (t2,v2), ....  (t'm,v'm)],  and  tu  t2, . . . ,  tn,t\ ,  t2,  ■  ■ . ,  t'm 
are  distinct,  then 

occ[ei  .  I  .  e2]  T  t  —  [(ti,u>i),  (t2,w2),  •  ■  • ,  (rn+m>  Wn+m)], 

where  ts  =  . . .  ,tn, fi,f2i  *  •  •  >*m}>  arid 

J  (tj^Vj)  tj  is  the  z-th  smallest  of  ts 
Tl’Wl  tfk  is  the  i-th  smallest  of  ts 

Note  that  we  require  the  occurrence  times  are  distinct,  be¬ 
cause  the  result  of  merging  two  simultaneous  occurrences  is 
nondeterministic. 


We  can  show  that  the  implementation  of  ( .  I  . )  converges 
to  its  semantics.  To  save  space,  we  don’t  give  the  formal 
statement  here. 


Behavior  Switching 

The  until  operator  is  implemented  as: 


>  until  : :  Behavior  a  ->  Event  (Behavior  a) 

>  ->  Behavior  a 

>  fb  'until'  fe  = 

>  \ts  ->  loop  ts  (fe  ts)  (fb  ts) 

>  where  loop  tsOCitsO  ~(e:es)  (b:bs)  = 

>  b  :  case  e  of 

>  Nothing  ->  loop  ts’  es  bs 

>  Just  fb’  ->  tail  (fb*  ts) 
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and  its  semantics  is  given  by: 


If  occ[e]  T  t  =  [(<1,  [t>i J ),  •  • (tn,  [6„J)],  then  for  any  T  G 

[T<], 


at  [6  ‘  until  *  e]  T  r  = 


fat [6]  T  r 
|at[6ij  ti  t 


n  =  0  or  r  <  ti 
otherwise 


This  operator  is  precisely  where  behaviors  interact  with  events, 
and  thus  its  good  behavior  is  critical  to  the  goodness  of  FRP. 
We  can  show: 


>  when  : :  Behavior  Bool  ->  Event  () 

>  when  fb  = 

>  \ts  ->  zipWith  up  (True  :  bs)  bs 

>  where  bs  =  fb  ts 

>  up  False  True  =  Just  () 

>  up  „  _  »  Nothing 

We  define  the  semantics  of  when  as  follows:  Given  T,  t  E 
Time ,  let  fb(r)  =  at[6J  T  r.  If  there  are  ci,C2,...,cn  E 
Bool  and  a  partition  [to,  t\ , . . , ,  tn]  of  [T,  t],  such  that: 


Theorem  10.  If  occ* [e]  T  t  =  [(ti,  [6i J ), . . . ,  (tn,  IM)]> 
then  for  any  r  E  [T,  t]  where  r  ^  t\, 

at*[b  ‘  until  *  e]  T  r  = 

at*{b]  T  r  n  —  0  or  r  <  t\ 

lim^-^tj  at  [bi]  7]  r  otherwise 

Most  behaviors  are  continuous  with  respect  to  their  start 
times  (i.e.  a  small  change  in  the  start  time  only  results  in 
a  small  change  in  the  result  value);  for  example  this  is  true 
of  integral.  Some  behaviors  are  even  independent  of  the 
start  time,  as  with  time.  In  such  cases,  the  limit  operator  in 
the  above  theorem  can  be  dropped,  and  the  implementation 
becomes  consistent  with  the  semantics. 


1.  For  all  1  <  i  <  n  —  1,  Ci  =  -»Ci+i; 

2.  For  all  1  <  i  <  n  —  1,  r  E  (U-i,U)  implies  fb(r)  =  c*; 

3.  fb(T)  ^  _L  or  C\  =  False,  and 

4.  fb(t)  /  _L  or  cn  =  True. 

then  occ[when  6]  T  t  =  occs  ^  _L,  where  occs  is  the  shortest 
time-ascending  list  satisfying: 

1.  If  ci  =  True  and  fb(T)  =  False,  then  (T,  ())  E  occs; 

2.  For  1  <  i  <  n  —  1,  (ti,  ())  €  occs  if  C{  —  False,  and 

3.  If  cn  —  False  and  fb(t)  =  True,  then  (t,  ())  6  occs. 


Snapshot 

snapshot  samples  a  behavior  at  the  exact  moments  an  event 
occurs. 

>  snapshot  : :  Event  a  ->  Behavior  b 

>  ->  Event  (a,b) 

>  snapshot  fe  fb 

>  =  \ts  ->  zipWith  aux  (fe  ts)  (fb  ts) 

>  where  aux  (Just  x)  y  =  Just  (x,y) 

>  aux  Nothing  _  =  Nothing 

The  semantics: 

If  occfe]  T  t  =  [(ti,ai),  (t2,a2), . . . ,  (tn,an)]  andat[hj  T  U  = 
bi ,  then 

occ|e  ‘snapshot'  6]  T  t  = 

[(ti,  (ni,6i)),  (t2,  (02,62)),  •  ■ . ,  ( tn ,  (On,6n))] 

The  implementation  is  faithful  to  the  semantics  uncondi¬ 
tionally: 

Theorem  11.  If  occ*[e\  T  t  =  [(ti,ai),  (£2,a2),  •  •  • , 
(tn,on)]  and  at  *  [6J  T  ti  =bl}  then 

occ *  [e  *  snapshot  *  6]  T  t  = 

[(<l,(0l,6l)),  (<2 ,  (02,62)),  -  •  -,(<«,  (On,6n))] 

Predicate  Events 

We  can  turn  a  Boolean  behavior  into  an  event  that  occurs 
every  time  the  behavior  changes  from  False  to  True.  To  do 
so  we  use  the  when  combinator  defined  as: 


Otherwise  occ  [when  6]  T  t  —  1. 

This  may  seem  complicated,  but  it  basically  says  that  when  b 
has  an  occurrence  at  time  r  iff  at  [6]  T  7]  (viewed  as  a  func¬ 
tion  of  7])  jumps  from  False  to  True  as  77  crosses  point  r 
from  the  left  (i.e.  the  negative  side). 

According  to  this  rule,  if  fb(r)  toggles  its  value  back  and 
forth  instantaneously  at  some  to  €  (T,  t),  then 

occ  [when  6j  T  t  =  _L.  To  see  why  this  is  true,  suppose 
occ  [when  6]  T  t  ^  _L,  then  there  must  be  ci,...,cn  and 
to,..., in  satisfying  the  above  constraints.  In  addition,  To 
must  be  equal  to  tu  for  some  1  <  k  <  n  —  1,  because  fb(r) 
remains  constant  in  each  of  ($i-i,t*)  where  1  <  i  <  n.  How¬ 
ever,  this  means  Ck  =  cjt+i,  which  violates  the  constraint 

d  = 

This  rule  implies  that  on  any  finite  time  interval,  a  predicate 
event  can  only  occur  a  finite  number  of  times  (for  the  num¬ 
ber  n  above  is  finite).  Therefore,  if  the  Boolean  behavior 
ever  oscillates  at  an  infinite  frequency  (we  will  see  such  an 
example  later),  the  semantics  of  the  event  is  J_. 

The  implementation  of  when  b  is  faithful  to  the  semantics  if 
the  implementation  of  b  converges  uniformly: 

Theorem  12.  Given  a  time  interval  [T,  £],  ifat[bj  P J  >— ► 
fb(r)  uniformly  on  [T,  t] ,  then 

occ* [when  6]  T  t  =  occ[when  b}  T  t. 

We  require  at [6]  Pf  >-»■  fb(r)  uniformly  on  [T,t],  because 
the  meer  existence  of  at  [6]  T  r  is  not  sufficient  here.  For 
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example,  given  the  behavior  bizarre  we  discussed  in  Section 

6,  at*  [bizarre  >*  lj  0  r  =  False  for  every  r  G  [0, 1],  and 
thus  occ[when  (bizarre  >*  1)]  0  1  =  [],  but 

occ*  [when  (bizarre  >*  1)J  0  1  =  [(0,  ())]  #  [] 

7.  EGREGIOUS  BEHAVIORS  AND  EVENTS 

As  mentioned  earlier,  it  is  possible  to  define  certain  egregious 
behaviors  and  events  in  FRP,  and  a  good  understanding 
of  them  is  helpful  in  understanding  the  semantic  rules  and 
theorems  that  we  have  introduced.  Consider  first  this  event: 

>  sharp  : :  Event  0 

>  sharp  ~  when  (time  ==*  1) 

This  looks  innocent  enough,  but  the  predicate  is  true  only 
instantaneously  at  time  =1.  To  sample  sharp,  let’s  con¬ 
sider  a  series  of  partitions  {Pn  \  n  G  N}  of  [0, 2],  where  Pn  = 

t°-  sAt- 2At---->^+T>2]-  Obvious*y  limn-ocIPnl  =  0, 

however  none  of  the  partitions  divides  [0,  2]  at  point  1.  Hence 
our  sampling  based  implementation  could  fail  to  find  the 
event  occurrence  at  time  1 .  This  explains  why  our  semantic 
rule  for  when  gives  _1_  as  the  denotation  of  sharp. 

It  is  worth  pointing  out  that  one  can  write  a  well-behaved 
definition  for  sharp: 

>  sharp2  =  when  (time  >=*  1) 

Consider  next  this  encoding  of  Zeno’s  Paradox : 

>  zeno  : :  Event  () 

>  zeno  =  when  (liftl  f  time)  where 

>  f  t  =  t  <  2  &&  even  (floor  (log2  (2  -  t))) 

This  example  demonstrates  an  infinitely  dense  sequence  of 
events  at  times  to  =  1,  t\  =  1.5,  ti  =  1.75,  and  in  gen¬ 
eral  tn+ 1  =  tn  +  2“(n+1\  This  creates  obvious  problems 
with  an  implementation.  But  even  if  we  could  implement 
such  event  sequences,  there  is  a  more  fundamental  semantic 
problem.  Suppose  there  is  an  electric  light  in  a  room,  ini¬ 
tially  off.  A  daemon  comes  in  and  turns  the  light  on  at  time 
£o,  off  at  time  ti ,  and  so  on.  A  simple  calculation  shows  that 
limn-Hx>  tn  =  2,  so  the  whole  process  comes  to  an  end  at  time 
t  —  2.  Now  the  question  is:  is  the  light  on  or  off  after  the 
daemon  stops?  The  answer  might  be  surprising:  it  could  be 
either  on  or  off;  i.e.,  this  is  a  natural  expression  of  nondeter¬ 
minism.  Our  semantic  rules  give  that  occ[zeno]  T  t  =  ±  for 
any  T  <  2  <  t,  which  provides  no  information  about  what 
the  implementation  will  give  us,  and  therefore  is  compatible 
with  the  nondeterministic  semantics  one  might  expect. 

Finally,  consider  this  unpredictable  behavior: 


In  a  stream-based  implementation,  we  don’t  know  what 
value  unpredictable  will  yield  at  run  time,  since  it  depends 
on  the  sampling  frequency  and  phase.  For  this  example,  the 
semantic  rules  give  a  value  in  terms  of  sin  where  t  =  1, 
which  is  undefined  due  to  the  discontinuity  of  the  function. 

sharp,  zeno  and  unpredictable  are  all  examples  where  the 
semantics  is  _L.  There  are  other  egregious  values  where  the 
semantics  is  not  ±,  but  the  implementation  does  not  agree 
with  it.  integal  bizarre  is  one  of  them. 

8.  INTERFACE  WITH  REAL  WORLD 

As  was  mentioned  earlier,  behaviors  and  events  can  also  re¬ 
act  to  user  actions,  which  we  can  capture  formally  through 
the  notion  of  an  environment ,  which  can  be  viewed  as  a  fi¬ 
nite  set  of  primitive  behaviors  and  events.  Thus,  strictly 
speaking,  the  semantic  functions  should  have  type: 

at  :  (Behavior^)  — >  Env  — >  Time  -4  Time  — >  a 

occ  :  (Events)  -4  Env  — >  Time  -4  Time  -4  [Time  x  a] 

where  Env  is  the  abstract  data  type  for  all  the  input  to  the 
FRP  system. 

For  example,  in  Fran,  the  environment  includes  mouse  move¬ 
ments,  mouse  button  presses,  and  keyboard  presses.  Thus 
we  can  define  Env  —  PBehintxint  x  PEvt()  x  PEvt( )  x 
PEntchar,  where  the  four  components  of  the  tuple  correspond 
to  mouse  position,  left  button  press,  right  button  press  and 
keyboard  press,  respectively.  Type  of  the  form  PBeha  and 
PEvta  are  defined  as: 

PBeha  =  Time  -4  a 
PEvta  =  Time  -4  [Time  x  a] 

This  idea  can  be  justified  by  noting  that  primitive  behaviors 
and  events  are  in  fact  observations  of  physical  signals  outside 
of  the  FRP  system.  Their  values  at  a  particular  time  do  not 
depend  on  when  we  start  the  observation.  Therefore  a  value 
of  type  PBeha  is  just  a  mapping  from  the  current  time  to 
the  value,  and  a  value  of  type  PEvta  is  a  mapping  from 
current  time  to  all  the  occurrences  since  the  initialization  of 
the  system. 

The  treatment  of  environment  is  almost  orthogonal  to  the 
treatment  of  the  individual  FRP  operators.  This  allows  us 
to  address  the  issue  separately.  To  extend  the  stripped-down 
version  of  FRP  to  incorporate  environments,  we  need  only 
to: 

1.  Define  the  semantics  for  the  FRP  constructs  that  rep¬ 
resent  user  actions. 

For  mouse  ::  Behavior  (Int ,  Int) ,  we  have: 

at[mouse|  {mouse ,lbp,rbp,  key)  T  t  =  mouse  t. 

For  lbp  :  :  Event  ( ) ,  we  have: 

occ[lbp]  (mouse,  lbp,  rbp,  key)  T  t~  after  T  ( lbp  t), 

where  after  T  list  drops  all  elements  in  list  whose 
time-stamp  is  less  than  or  equal  to  T. 


>  unpredictable  : :  Behavior  Real 

>  unpredictable  = 

>  0  ‘until'  (when  (time  >*  1) 

>  ‘snapshot'  sin  (l/(time  -  1)) 

>  ==>  (\(_,x)  ->  liftO  x)) 


2.  Pass  the  environment  parameter  around  in  the  seman¬ 
tic  equations  for  composite  behaviors/events.  For  in- 
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stance,  the  meaning  for  lift2  is  now  given  by: 
at[lift2  /  b\  62J  env  T  t  = 

L/J  (at[bi]  env  T  0  (atIM  env  T  t) 

9 .  CONCLUSIONS  AND  RELATED  WORK 

Although  the  signal  processing  literature  is  full  of  founda¬ 
tional  work  on  the  validity  and  accuracy  of  sampling  tech¬ 
niques,  we  are  not  aware  of  any  work  attempting  to  define 
the  semantics  of  a  reactive  programming  language  such  as 
FRP.  Also,  most  of  the  signal  processing  work  shies  away 
from  discontinuous  signals,  whereas  we  have  shown  that  un¬ 
der  the  right  conditions  values  are  still  well  behaved. 

In  [7]  we  described  a  denotational  semantics  for  Fran.  The 
semantics  given  in  this  paper  is  different  in  that  it  parame¬ 
terizes  the  start  time  for  behaviors  and  events,  and  contains 
a  more  precise  characterization  of  events.  Various  imple¬ 
mentation  techniques  for  Fran  are  discussed  in  [6],  including 
the  basic  ideas  behind  a  stream-based  implementation;  in 
[10]  the  particular  implementation  used  in  this  paper  is  de¬ 
scribed  in  detail. 

It  is  worth  noting  that  we  concentrated  here  on  just  one  im¬ 
plementation  technique  for  FRP;  it  may  well  be  that  other 
techniques  either  have  more  or  fewer  constraints  than  those 
discovered  for  streams.  In  particular,  it  is  worth  pointing 
out  that  interval  analysis  can  be  used  to  safely  capture  in¬ 
stantaneous  predicate  events  [6,  7]. 

Finally,  we  point  out  that  all  of  our  results  depend  on  suffi¬ 
cient  accuracy  of  the  underlying  number  system  implemen¬ 
tation.  In  the  limit,  of  course,  that  requires  an  implementa¬ 
tion  of  exact  real  arithmetic.  Numerical  analysis  techniques 
are  ultimately  needed  to  ensure  the  stability  of  any  system 
based  on  floating-point  numbers. 

CML  (Concurrent  ML)  formalized  synchronous  operations 
as  first-class,  purely  functional,  values  called  “events”  [15]. 
Our  event  combinators  I  .”  and  “==>”  correspond  to 
CML’s  choose  and  wrap  functions.  There  are  substantial 
differences,  however,  between  the  meaning  given  to  “events” 
in  these  two  approaches.  In  CML,  events  are  ultimately  used 
to  perform  an  action ,  such  as  reading  input  from  or  writing 
output  to  a  file  or  another  process.  In  contrast,  our  events 
are  used  purely  for  the  values  they  generate.  These  values 
often  turn  out  to  be  behaviors,  although  they  can  also  be 
new  events,  tuples,  functions,  etc. 

Concurrent  Haskell  [12]  contains  a  small  set  of  primitives 
for  explicit  concurrency,  designed  around  Haskell’s  monadic 
support  for  I/O.  While  this  system  is  purely  functional  in 
the  technical  sense,  its  semantics  has  a  strongly  imperative 
feel.  That  is,  expressions  are  evaluated  without  side-effects 
to  yield  concurrent,  imperative  computations,  which  are  ex¬ 
ecuted  to  perform  the  implied  side-effects.  In  contrast,  mod¬ 
eling  entire  behaviors  as  implicitly  concurrent  functions  of 
continuous  time  yields  what  we  consider  a  more  declarative 
feel. 

Several  languages  have  been  proposed  around  the  synchronous 
data-flow  notion  of  computation.  The  general-purpose  func¬ 
tional  language  Lucid  [16]  is  an  example  of  this  style  of  lan¬ 
guage,  but  more  importantly  are  the  languages  Signal  [8], 


Lustre  [4],  and  Esterel  [2,  3]  which  were  specifically  designed 
for  control  of  real-time  systems.  In  Signal,  the  most  funda¬ 
mental  idea  is  that  of  a  signal ,  a  time-ordered  sequence  of 
values.  Unlike  FRP,  however,  time  is  not  a  value,  but  rather 
is  implicit  in  the  ordering  of  values  in  a  signal.  By  its  very 
nature  time  is  thus  discrete  rather  than  continuous,  with 
emphasis  on  the  relative  ordering  of  values  in  a  data-flow¬ 
like  framework.  The  designers  of  Signal  have  also  developed 
a  clock  calculus  with  which  one  can  reason  about  Signal  pro¬ 
grams.  Lustre  is  a  language  similar  to  Signal,  rooted  again 
in  the  notion  of  a  sequence,  and  owing  much  of  its  nature 
to  Lucid. 

Esterel  is  perhaps  the  most  ambitious  language  in  this  class, 
for  which  compilers  are  available  that  translate  Esterel  pro¬ 
grams  into  finite  state  machines  or  digital  circuits  for  em¬ 
bedded  applications.  More  importantly  in  relation  to  our 
current  work,  a  large  effort  has  been  made  to  develop  a  for¬ 
mal  semantics  for  Esterel,  including  a  constructive  behav¬ 
ioral  semantics,  a  constructive  operational  semantics,  and  an 
electrical  semantics  (in  the  form  of  digital  circuits).  These 
semantics  are  shown  to  correspond  in  a  certain  way,  con¬ 
strained  only  by  a  notion  of  stability. 
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APPENDIX 

A.  PROOF  OF  THEOREMS 

We  first  point  out  the  following  useful  property  that  every 
behavior  and  event  observes: 

Definition  f.  (n-equality)  Given  an  integer  n  and  two 
lists  /i  and  £2,  if 

length  l\  >  n,  length  I2  >  n,  and 
take  n  h  =  take  n  I2, 

then  we  say  that  l\  and  I2  are  n- equal,  which  we  write  as 

h=  12- 

Lemma  1.  For  any  b€  (Behaviora) ,  e  €  {Eventa) ,  ts,tsf  € 
[Time],  and  n  €  N,  ts  =  ts'  implies  that: 

[6J  ts  =  [6J  ts* ,  and 
[ej  ts  =  [ej  ts9. 

This  Lemma  essentially  says  that  the  current  value  of  a  be¬ 
havior  or  event  does  not  depend  on  the  future.  The  proof 
of  this  lemma  is  an  induction  on  the  syntactic  structure  of 
an  FRP  expression. 


Lemma  2.  [liftlj  /  b  ts  —  map  f  (b  ts). 

Proof. 

[liftlj  f  bts 

—  ([liftOj  /  [$*J  6)  ts  (definition  of  liftl) 

=  (A  ts.zipWith  L($)J  ([liftOj  f  ts)  {bts))  ts 
(definition  of  $*) 

=  zipWith  [($)J  ([liftOj  f  ts)  (b  ts) 

=  zipWith  [($)J  {map  {const  f)  ts)  {b  ts) 
(definition  of  liftO) 

=  map  f  {b  ts) 

□ 

Lemma  3.  [Iift2j  /  b\  62  ts  =  zipWith  f  {b\  ts)  (&2  ts). 
The  proof  is  not  hard  and  omitted. 

Theorem  1 

Proof.  For  any  e  >  0,  let  5  =  1,  for  any  Pf  such  that 
\Pf\  <  5,  we  have 

at  [time]  Pf 

=  last  ([timej  Pt)  (definition  of  at) 

=  last  Pt  (definition  of  time) 

=  t 

Hence  |ai[time]  P>f  —  t\  —  0  <  e.  □ 

Theorem  2 

Proof.  For  any  e  >  0,  let  8  =  1,  for  any  Pj-  such  that 
\Pt\  <  S,  we  have 

at  [liftO  cj  Pt 
=  last  ([liftO  cj  Pt) 

=  last  ([liftOj  [cj  Pt) 

—  last  [map  {const  [cj )  Pf)  (definition  of  liftO) 

=  LcJ 

Hence  |a£[liftO  c]  Pf-  -  [cj  |  =  0  <  e.  □ 

Theorem  3 

Proof. 

bt  =  lim  at{bj  Pt 

\prh° 

Thus 


L/J  bt 

=  L/J  ( 

lim  at|6]  Pt 

Vi 

I^tH0 

=  lim 

L/J  (ot[61P^) 

Kh° 

([/J  is  continuous  at  lim|pt  at [6J  Pf) 

=  ,  lim  L/J  (1^  (IAI  Pt)) 

\prh° 
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□ 


lim  last  ( map  [/J  ([b\  Pt)) 

\pfh° 

lim  last  ([liftlj  [/J  [6J  Pf) 

(lemma  2) 
at*  [liftl  f  b]  T  t 


Theorem  4 

Proof.  For  any  e  >  0,  since  [/ J  is  uniformly  continuous, 
there  is  an  g  >  0,  such  that  for  any  v,  v\  \v  —  v'\<g  implies 
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there  is  a  8  >  0,  such  that  for  every  t  E  S,  \Pf\  <  8  implies 
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where  ei  =  |at[/|  Pi  —  at*  [fj  T  ti|  . 

Since  at|/|  Pf  >— >  at*|/]  T  r  uniformly  converges  on  [T,  t], 
for  every  given  e  >  0,  there  is  a  8  >  0,  such  that  els  long  as 
\Pf\<8, 

ei  <  e,  for  every  1  <  i  <  length  Pf. 


Corollary  1 

Proof.  Since 

at  [time]  Pf^t  uniformly  on  (— 00,00) 

(by  theorem  1),  and  [sinj  =  sin  is  uniformly  continuous,  we 
have 

at|liftl  sin  time]  Pf  >— >  sin  t 
uniformly  on  (—oo,  oo)  (by  theorem  4), 

According  to  the  definition  of  lifted  sin: 

>  instance  Floating  a  =>  Floating  (Behavior  a)  where 

>  sin  =  liftl  sin 

we  have 

at[sin  time]  Pf  >— »  sint  uniformly  on  (—00,00). 
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Thus  when  \Pf\  <  8,  for  every  r  E  [T,  t]  we  have 
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Since  e  is  arbitrary,  atfintegral  /]  Pf  uniformly  converges 
to  ff  (at*  [/]  T  g)  dij.  □ 


Theorem  10 

Proof.  If  occ\e\  T  t  =  [],  then  there  is  a  8  >0  such  that 
for  every  partition  Pf  of  [T,  t]  where  \Pf\  <  8 , 
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Theorem  7 

Proof.  For  any  r  E  [T,  t], 
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If  occ*|e]  T  t  =  [(ti,  [6iJ), . . . ,  (tm,  L^mJ)],  where  m  >  0, 
then  for  a  partition  P  =  [go,  g\, . . . ,  gn]  of  [T,  t],  when  |P| 
is  small  enough,  justValues  P  ([ej  P)  will  have  m  ele¬ 
ments.  Let  the  first  of  the  m  elements  be  (gk,\bf\)}  and 
pk  =  [gk^gk+l  ,...,7?n],  then 
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APPENDIX  B 


DALI:  An  Untyped,  CBV  Functional  Language  Supporting 
First-Order  Datatypes  with  Binders 

(  Summary* ) 

Emir  Pasalic,  Tim  Sheard,  Walid  Tahaf 


ABSTRACT 

Writing  (meta-)programs  that  manipulate  other  (object-) 
programs  poses  significant  technical  problems  when  the  object- 
language  itself  has  a  notion  of  binders  and  variable  occur¬ 
rences.  Higher-order  abstract  syntax  is  a  representation  of 
object  programs  that  has  recently  been  the  focus  of  several 
studies.  This  paper  points  out  a  number  of  limitations  of 
using  higher  order  syntax  in  a  functional  context,  and  ar¬ 
gues  that  DALI,  a  language  based  on  a  simple  and  elegant 
proposal  made  by  Dale  Miller  ten  years  ago  can  provide 
superior  support  for  manipulating  such  object-languages. 
Miller’s  original  proposal,  however,  did  not  provide  any  for¬ 
mal  treatment.  To  fill  this  gap,  we  present  both  a  big-step 
and  a  reduction  semantics  for  DALI,  and  summarize  the  re¬ 
sults  of  our  extensive  study  of  the  semantics,  including  the 
rather  involved  proof  of  the  soundness  of  the  reduction  se¬ 
mantics  with  respect  to  the  big-step  semantics.  Because  our 
formal  development  is  carried  out  for  the  untyped  version 
of  the  language,  we  hope  it  will  serve  as  a  solid  basis  for 
investigating  type  system(s)  for  DALI. 

1.  INTRODUCTION 

Programs  are  data.  Nothing  makes  this  point  stronger  than 
the  ever  increasing  need  for  reliable  programs  with  verified 
properties.  As  software  systems  become  more  complex,  and 
play  increasingly  important  roles  in  critical  systems  there  is 
an  ever  increasing  need  for  optimizing,  analyzing,  verifying 
and  certifying  software. 

Each  one  of  these  tasks  involves  automatic  manipulation 

*  The  complete  technical  development  appears  in  a  technical 
report  available  online.  This  paper  focuses  on  the  describ¬ 
ing  DALI  from  the  point  of  view  of  language  design  and 
programming. 

t  Sheard  and  Pasalic  are  supported  by  the  USAF  Air  Ma¬ 
teriel  Command,  contract  #  F19628-96-C-0161,  NSF  Grants 
CCR-9803880  and  IRI-9625462,  and  the  Department  of  De¬ 
fense.  Taha  is  supported  by  a  Postdoctoral  Fellowship, 
funded  by  the  Swedish  Research  Council  for  Engineering 
Sciences  (TFR),  grant  number  221-96-403. 


of  programs  or,  meta-programming .  As  with  any  kind  of  pro¬ 
gramming,  effective  meta-programming  relies  heavily  on  the 
presence  of  the  appropriate  support  from  the  (meta-)  pro¬ 
gramming  language.  The  goal  of  this  paper  is  to  advocate  a 
novel  approach  to  representing  programs  in  a  manner  supe¬ 
rior  to  the  main  contenders  available  today.  Our  approach 
gives  rise  to  a  simple  equational  theory  that  can  be  used  to 
reason  about  the  program  equivalence  of  met  a- programs. 

1.1  Meta-Programming  as  Programming 

It  is  our  thesis  that  traditional  programming  language  tech¬ 
niques,  including  those  from  the  operational,  categorical,  ax¬ 
iomatic,  and  denotational  traditions  can  be  applied  equally 
effectively  to  met  a- programming  languages  [45].  In  many 
instances,  this  means  that  the  technical  challenge  is  “inter¬ 
nalizing”  various  meta-level  operations,  such  as  quotation 
[49],  evaluation  [48;  29;  4;  45;  47],  and  type  analysis  [44; 
46],  into  a  formal  programming  language,  and  subjecting 
them  to  the  same  high  standards  developed  by  the  seman¬ 
tics  community.  This  approach  has  numerous  pragmatic 
benefits,  including: 

1.  We  succeed  in  magnifying  the  subtle  features  of  the 
operations  under  investigation,  and,  often  times,  in 
addressing  them  in  a  systematic  and  complete  man¬ 
ner.  From  the  software  engineering  point  of  view,  this 
translates  into  enhanced  safety  and  reliability. 

2.  We  succeed  in  assigning  a  uniform  semantics  to  these 
operations  that  must  otherwise  be  carried  out  in  an 
ad  hoc  fashion.  This  can  be  done  to  the  extent  that 
we  can  provide  mathematically  verified  reasoning  prin¬ 
ciples  for  these  operations  in  the  form  of  equational 
theories.  From  the  software  engineering  point  of  view, 
this  translates  into  enhanced  correctness. 

3.  We  make  these  operations  available  to  the  programmer 
in  a  uniform  way,  thus  providing  more  him  or  her  with 
more  control  over  the  behavior  of  the  system.  From 
the  software  engineering  point  of  view,  this  translates 
into  enhanced  predictability. 

1.2  Synthesis  vs.  Analysis 

There  are  two  different  kinds  of  program  manipulation:  pro¬ 
gram  synthesis ,  and  program  analysis.  The  combination  of 
the  two  is  necessary  for  expressing  general  program  trans¬ 
formations.  In  what  follows  we  outline  the  state  of  the  art 
in  language  support  for  both  synthesis  and  analysis,  and  ex- 
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plain  how  the  present  work  on  DALI  fits  in  the  context  of 
analysis. 

7.2. 7  Synthesis  and  Multi-Stage  Programming 
Many  recent  studies  have  concentrated  on  language  level 
support  for  program  synthesis:  works  on  multi-level  [12;  11; 
30;  28]  and  multi-stage  [49;  48;  29;  4;  45;  47]  programming 
languages  have  investigated  basic  problems  relating  to  lan¬ 
guage  support  needed  for  program  synthesis  such  as  how 
to  build  program  fragments,  how  to  combine  smaller  pro¬ 
gram  fragments  into  larger  ones,  and  how  to  execute  such 
fragments  in  a  user  friendly,  hygienic,  and  type-safe  manner. 
But  while  multi-stage  programming  constructs  provide  good 
support  for  the  construction  and  execution  of  object-code, 
they  provide  no  support  for  analysis.  In  fact,  adding  con¬ 
structs  for  analyzing  code  fragments  can  severely  weaken  the 
notion  of  observational  equivalence  in  such  languages  [47]. 

7.2.2  Analysis  and  Higher  Order  Syntax 
In  contrast,  substantially  fewer  studies  have  focused  on  lan¬ 
guage  level  support  for  program  analysis  [21;  39;  13].  With 
few  exceptions  (see  for  example  Bjorner  [5]),  the  most  pop¬ 
ular  tool  for  these  studies  has  been  higher  order  abstract 
syntax[3S]  (HOAS),  and  have  taken  place  in  the  context  of 
logic  programming  languages  [1].  In  the  remainder  of  this 
paper  we  shall  (without  drawing  too  fine  a  distinction)  re¬ 
fer  to  all  approaches  to  syntax  that  represent  object-level 
binding  constructs  by  meta-language  binding  constructs  in 
a  uniform  way  as  higher- order  abstract  syntax. 

A  program  analysis  inspects  the  structure  and  environ¬ 
ment  of  an  object-program  and  computes  some  value  as  a 
result.  Results  can  be  data-  or  control-flow  graphs,  or  even 
another  object-program  with  properties  based  on  the  prop¬ 
erties  of  the  source  object-program.  Examples  of  these  kinds 
of  met  a- systems  are:  program  transformers,  optimizers,  and 
partial  evaluation  systems  [22]. 

Program  analyses  are  particularly  difficult  to  write  cor¬ 
rectly  if  they  must  manipulate  terms  that  have  a  notion  of 
statically  scoped  variables.  The  exact  representation  of  the 
variable  is  generally  uninteresting,  and  often  requires  sub¬ 
tle  administrative  changes  so  that  it  maintains  its  original 
“meaning” . 

The  primary  example  of  such  administrative  changes  is 
a  renaming  when  the  “direct”  representation  of  variables  is 
used,  and  “shift”  and  “lift”  operations  when  de  Bruijn  in¬ 
dices  are  used.  The  first  representation  relies,  typically,  on 
the  use  of  state,  a  “gensym”  operation,  and  the  second  rep¬ 
resentation  is  generally  considered  “too  human  unfriendly” . 
Because  of  this,  representing  object-programs  using  first  or¬ 
der  algebraic  data  structures  which  use  strings  or  other 
atomic  values  to  represent  variables  are  notoriously  hard  to 
manipulate  correctly. 

A  more  pressing  concern  is  that  implementing  such  oper¬ 
ations  once  is  not  enough:  They  need  to  be  implemented  for 
each  object-language  that  has  binding  constructs .  The  basic 
problem  is  therefore  pervasive,  it  appears  in  almost  every 
interesting  language. 

The  basic  idea  that  we  advocate  is  to  (uniformly)  exploit 
the  binding  mechanism  of  the  meta-language  to  implement 
the  binding  mechanism(s)  of  the  object-language,  i.e.  use 


functions  in  the  meta-language  to  implement  binding  in  the 
object-language.  At  first  glance,  this  looks  like  a  promising 
idea,  but  a  number  of  subtle  problems  arise.  We  explicate 
these  problems  carefully  in  Section  3.  The  problems  arise 
because  the  functions  of  the  meta-language  have  two  prop¬ 
erties  which,  while  necessary  for  their  use  as  functions,  get 
in  the  way  of  their  use  as  binding  mechanisms.  These  prop¬ 
erties  are:  extensionality  and  delayed  computation.  Exten- 
sionality  means  that  one  cannot  observe  the  structure  of  a 
function,  other  than  by  applying  it  to  get  a  result.  Delayed 
computation  means  that  computations  embodied  in  a  func¬ 
tion  do  not  occur  until  the  function  is  applied.  What  we 
need  is  a  new  kind  of  binding,  without  these  properties. 

In  this  paper,  we  develop  such  a  binding  mechanism  by 
refining  some  ideas  of  Dale  Miller’s  [23].  This  new  binding 
mechanism  can  be  incorporated  into  a  functional  language 
with  first-order  datatypes,  and  together  they  can  be  used  to 
represent  variable  binding  in  object-languages.  This  mecha¬ 
nism  can  be  systematically  reused.  In  addition,  we  develop  a 
sound  syntactic  system  for  reasoning  about  the  equivalence 
of  functional  programs  that  use  this  new  binding  mechanism. 


1.3  Contribution 

The  contribution  of  this  paper  is  simple  and  focused:  a  call- 
by-value  operational  semantics  for  an  untyped  functional 
programming  language  with  an  extension  that  supports  first- 
order  datatypes  (FOD)  with  binders. 

We  have  applied  the  rigorous  standards  of  language  de¬ 
sign  and  semantic  analysis  to  both  the  host  language  (the 
lambda  calculus)  and  the  extension  and  discovered  that  the 
two  are  mutually  compatible.  The  combined  language  en¬ 
joys  a  non-trivial  equational  theory  where  beta  convertibility 
is  a  congruence,  and  is  therefore  unlikely  to  invalidate  known 
optimizations  for  a  call-by-value  functional  language. 

We  believe  that  our  present  operationally-based  study 
complements  the  recent  model-theoretic  approach  of  Gab- 
bay  and  Pitts  [17],  Hofmann  [20],  and  Fiore,  Plotkin,  and 
Turi  [16].  For  example,  whereas  Pitts  and  Gabbay’s  recent 
work  emphasizes  that  a  type  system  is  required  for  their 
language  to  ensure  that  “namefulness”  doesn’t  spread  ev¬ 
erywhere,  our  language  is  untyped,  and  does  not  appear  to 
give  rise  to  any  non-standard  “namefulness”  problems. 


2.  HOAS  V.S.  FIRST  ORDER  DATATYPES 

The  precise  semantics  of  (meta-) programs  depends  crucially 
on  the  basic  properties  of  the  representation  of  object-programs. 
This  question  of  representation  is  the  focus  of  the  present 
study. 

The  essence  of  the  representation  we  propose  goes  back  at 
least  to  Church  [8].  The  idea  is  to  exploit  the  binding  mech¬ 
anism  of  the  meta-language  to  implement  the  binding  mech¬ 
anism^)  of  the  object-language.  This  is  also  the  essence  of 
Pfenning  and  Elliot  [38]  and  Miller’  [23;  25;  26]  higher-order 
syntax  (HOAS)  representation.  To  illustrate  the  basic  idea 
of  higher-order  syntax,  consider  the  definitions  of  Term  and 
Term’  below. 


23 


data  Term 
=  App  Term  Term 
|  Abs  String  Term 
I  Const  Int 
j  Var  String 


data  Term’ 

=  App'  Term’  Term’ 

I  Abs*  Term’  ->  Term’ 
I  Const  ’  Int 


In  Term 7  we  represent  the  object-language  lambda  abstrac¬ 
tion  (Abs*)  using  the  meta-language  function  abstraction. 
This  way,  functions  such  as  id  and  app  are  represented  by 
applying  the  Abs’  constructor  to  a  meta-language  function: 


—  \  x  ->  x 

id  =  Abs  "x"  (Var  "x") 


—  \  x  ->  x 

id'  =  Abs ’  (\  x  ->  x) 


—  \f  ->  \  x  ->  f  x 
app  =  Abs  "f" 

(Abs  "x" 

(App  (Var  "f") 
(Var  "x"))) 


—  \f  ->  \  x  ~>  f  x 
app*  =  Abs’  (\  f  -> 
Abs  *  (\  x  -> 
(App*  f  x))) 


The  HOAS  representation  (Term’)  is  elegant  in  that  a  con¬ 
crete  representation  for  variables  is  not  needed,  and  that  it  is 
not  necessary  to  invent  unique,  new  names  when  construct¬ 
ing  lambda-expressions  which  one  can  only  “hope”  don’t 
clash  with  other  names. 


3.  CRITIQUE  OF  HOAS 

This  flavor  of  HOAS  seems  like  a  great  idea  at  first,  but 
careful  inspection  reveals  a  few  anomalies.  It  works  fine  for 
constructing  statically  known  representations,  but  quickly 
breaks  down  when  trying  to  construct  or  observe  a  represen¬ 
tation  in  a  algorithmic  way.  We  quickly  provide  a  few  small 
examples  that  illustrate  the  problems  we  have  encountered. 

Pi  Opaqueness:  We  cannot  pattern  match  or  observe 
the  structure  of  the  body  of  an  Abs’,  or  any  object- 
level  binding,  because  they  axe  represented  as  func¬ 
tions  in  the  met  a- language,  and  meta-level  functions 
are  extensional. 

We  can  observe  this  by  casting  our  Term*  example 
above  into  a  real  program  formulated  in  ML,  and  notic¬ 
ing  that  id  prints  as  Abs’  fn. 

(*  Actual  ML  Program  Execution  *) 

-  datatype  Term, 

=  App*  of  (Term’*  Term’) 

|  Abs*  of  (Term*  ->  Term’) 

I  Const’  of  int; 

-  val  id  -  Abs’(fn  x  =>  x) ; 
val  id  =  Abs’  fn  :  Term’ 

P2  Junk  [7;  6]  :  I.e.,  there  are  terms  in  the  meta-language 
with  type  Term’  that  do  not  represent  any  legal  object- 
program.  Consider: 

junk  =  Abs’(\  x  ->  case  x  of  App’  f  y  ->  y 

;  Const’  n  ->  x 
;  Abs’  _  ->  x) 

No  legal  object-program  behaves  in  this  way. 

P3  Latent  Divergence:  Because  functions  delay  com¬ 
putation,  a  non-terminating  computation  producing  a 
Term’  may  delay  non-termination  until  the  Term’  ob¬ 
ject  is  observed.  This  may  be  arbitrarily  far  from  its 
construction,  and  can  make  things  very  hard  to  debug. 
Consider  the  function  bad  below: 


bad  (Const’  n)  =  Const’  (n+1) 

bad  (App’  x  y)  =  App’  (bad  x)  (bad  y) 

bad  (Abs’  f)  =  Abs’(\  x  ->  diverge (bad  (f  x))) 

bad  walks  over  a  Term’  increasing  every  explicit  con¬ 
stant  by  one.  Suppose  the  programmer  made  a  mis¬ 
take  and  placed  an  erroneous  divergent  computation  in 
the  Abs  ’  clause.  Note  that  bad  does  not  immediately 
diverge. 

P\  Expressivity:  Using  HOAS,  there  exist  (too  many) 
meta-functions  over  object- terms  that  cannot  be  ex¬ 
pressed.  Consider  writing  a  show  function  for  Term’ 
that  turns  a  Term’  into  a  string  suitable  for  printing. 

show  (App’  f  x)  =  (show  f)  ++  "  *'  ++  (show  x) 

show  (Const’  n)  =  toString  n 

show  (Abs’  f)  =  "\\  "++  ?v  ++  "  ->  " 

++  (show  (f  ?v)) 

What  legal  met  a- program  value  do  we  use  for  ?v?  We 
need  some  sort  of  “variable”  with  type  Term’  but  no 
such  thing  can  be  created.  There  are  “tricks”  for  solv¬ 
ing  this  problem  [14],  but  in  the  end,  they  only  make 
matters  worse. 

Our  approach  to  these  problems  is  to  cast  our  search 
for  solutions  as  an  exercise  in  programming  language  de¬ 
sign.  The  following  subsections  offer  an  informal  discussion 
of  each  problem  and  a  potential  solution  by  the  introduc¬ 
tion  of  additional  language  features,  and  provide  examples 
of  how  these  language  features  might  be  used.  Our  biggest 
challenge  is  to  discover  features  that  interact  well,  both  with 
each  other,  and  with  the  existing  features  of  the  language 
we  wish  to  add  them  to. 

3.1  Opaqueness 

To  solve  the  opaqueness  problem  a  number  of  researchers 
have  investigated  the  use  of  higher-order  pattern  matching 
[32].  The  basic  idea  is  that  programmers  use  a  higher-order 
interface  to  the  object-language  because  it  is  expressive  and 
easy  to  use,  but  the  actual  underlying  implementation  is 
first  order. 

One  tries  to  supply  an  enriched  interface  that  gives  pro¬ 
grammers  access  to  this  first-order  implementation  in  a  safe 
manner,  that  still  supports  all  the  benefits  of  a  higher-order 
implementation.  To  illustrate  this  consider  the  (not  neces¬ 
sarily  semantics-preserving)  rewrite  rule  f  for  object-terms 
Term’,  which  might  be  expressed  as: 
f  :  (A  x.(e'O))  -¥  (e'[0/x]). 

Here,  we  use  the  notation,  that  a  primed  variable  is  a 
met  a- variable.  Thus  e'  is  a  meta-variable  of  the  rule,  and 
e'[0/:r]  indicates  the  capture  free  substitution  of  0  for  x  in 


Higher- order  pattern  matching  is  a  programming  language 
mechanism,  that  allows  us  to  express  that  we  wish  to  observe 
the  inner  structure  of  meta-language  abstraction,  and  that 
parts  of  the  body  of  this  abstraction  (i.e.  e')  may  have  free 
occurrences  of  x  inside. 

We  use  a  higher-order  pattern  when  we  wish  to  analyze 
the  structure  of  a  constructor  like  Abs  ’  which  takes  a  meta¬ 
function  as  an  argument.  Like  all  patterns,  a  higher  order 
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pattern  “binds”  a  meta-variable.  The  meta-variable  bound 
by  a  higher-order  pattern  does  not  bind  to  an  object-term, 
but  instead  binds  to  a  function.  This  function  captures  the 
subtlety  that  e'  might  have  free  occurrences  of  x.  Given 
the  bound  variable,  as  input,  it  reconstructs  the  body  of  the 
abstraction.  Given  a  term  as  input,  it  substitutes  the  term 
for  each  free  occurrence  of  the  bound  variable  in  the  body. 

The  bound  met  a- variable  is  a  function  from  Term,  -> 
Term’.  We  make  this  language  mechanism  concrete  by  ex¬ 
tending  the  notion  of  pattern  in  our  meta-language.  Pat¬ 
terns  can  now  have  explicit  lambda  abstractions,  but  any 
pat  tern- variables  inside  the  body  of  the  lambda  abstraction 
are  higher-order  pattern- variables,  i.e.  will  bind  to  func¬ 
tions.  Consider  below,  an  example  implementing  the  rewrite 
rule  above. 

f  (Abs’(\  x  ->  App’Ce’  x) (Const  0)))  =  e’ (Const  0) 
f  x  =  x 

In  this  example  the  meta-function  f  matches  its  argu¬ 
ment  against  an  object-level  abstraction  (Abs *  . . . )  using 
an  object-level  pattern.  The  pattern  specifies  that  the  body 
of  the  matched  abstraction  must  be  an  application  (App*)  of 
a  function  term  (e’  x)  to  a  constant  (Const  0).  The  func¬ 
tion  part  of  this  object- application  can  be  any  term.  This 
term  may  have  free  occurrences  of  the  object-bound  variable 
(which  we  write  as  x  in  the  pattern,  but  which  can  have  any 
name  in  the  object-term  it  matches  against).  Because  of 
this  we  use  a  higher-order  pattern  (e  *  x)  which  applies  e  to 
x  to  indicate  that  e’  is  a  function  whose  argument  is  the 
object-bound  variable  x. 

This  extension  differs  from  normal  pattern  matching,  in 
that  neither  meta-level  abstractions  (\  x  ->  .  . . )  nor  appli¬ 
cations  of  met  a- variables  (e  ’  x)  normally  appear  in  regular 
patterns. 

If  the  underlying  implementation  is  first  order  (like  Term), 
patterns  of  this  form  have  an  efficient  and  decidable  imple¬ 
mentation.  The  clause 

f  (Abs'(\  x  ->  App’ (e 1  x) (Const  0)))  =  e}  (Const  0) 
would  translate  into  an  implementation  using  Term  as  fol¬ 
lows: 

f  (Abs  x  (App  e  (Const  0)))  = 

let  e’  y  =  subst  [(x,y)]  e 
in  e*  (Const  0) 

The  key  advantage  of  this  approach  is  that  users  get  to  use 
the  expressive  and  safe  HOAS  interface,  and  the  substitution 
function  need  not  be  written  by  the  programmer  but  can  be 
supplied  by  the  underlying  implementation. 

The  solution  of  using  (a  hidden)  underlying  first  order 
implementation,  but  supplying  a  higher-order  interface,  ex¬ 
tends  nicely  to  term  construction  as  well  as  term  observa¬ 
tion. 

A  construction  like:  (Abs*  f)  ::  Term }  could  be  trans¬ 
lated  into  an  underlying  implementation  based  on  first-order, 
observable,  data-structures  (i.e.  Term)  by  using  a  gensym 
construct  to  provide  a  “fresh”  name  for  the  required  object- 
bound  variable: 

let  y  =  gensym  ()  in  Abs  y  (f  (Var  y)). 


Again  both  the  gensym  and  the  underlying  first-order  im¬ 
plementation  is  hidden  from  the  user. 

3.2  Junk 

Junk  is  a  serious  problem  in  that  it  allows  meta-programs  to 
represent  non-existent  terms  in  the  object-language.  Junk 
arises  because  the  body  of  an  object-binding  is  a  compu¬ 
tation  (i.e.  a  suspended  function),  rather  than  a  constant 
piece  of  data.  This  causes  two  kinds  of  problems: 

1.  The  computation  can  “observe”  the  bound  variable, 
and  do  ill-advised  things  like  pattern  matching.  A 
valid  object-binding  only  “builds”  new  structure  around 
the  variable.  It  does  not  observe  the  bound  variable. 

2.  The  computation  can  introduce  effects.  In  this  case  the 
computational  effects  of  the  meta-language,  such  as 
nontermination,  are  introduced  into  the  purely  syntac¬ 
tic  representation  of  the  object  language.  Even  worse, 
the  effects  are  only  introduced  when  the  object-term 
is  observed.  If  a  term  is  observed  multiple  times,  it 
causes  the  effects  to  be  introduced  multiple  times. 

3.3  Latent  Divergence 

So  we  see  that  that  junk  and  latent  divergence  are  really 
two  facets  of  the  same  problem.  To  fix  these  problems  we 
need  a  binding  construct  which  preserves  static  scoping  (like 
normal  meta-level  functions)  but  which  does  not  delay  com¬ 
putation.  What  we  need  is  a  binding  construct  which  forces 
computation  “under  the  lambda”  [45]. 

Ten  years  ago,  Dale  Miller  proposed  a  new  meta-level 
binding  construct  for  implementing  HOAS  in  ML  [23]  which 
did  exactly  this.  He  introduced  a  new  binary  type  construc¬ 
tor  (a  =>  b)  which  names  the  type  of  an  object  level  binding 
of  a  terms  in  b  terms.  The  new  type  constructor  was  used  in 
place  of  the  function  type  constructor  to  denote  object-level 
abstraction. 

We  introduce  DALI,  a  language  based  upon  a  refinement 
of  Miller’s  idea.  We  compare  it  to  HOAS,  and  illustrate  its 
intended  use  by  a  number  of  examples.  In  DALI,  the  object¬ 
binding  mechanism  is  separate  from  the  function  construct 
of  the  meta-language.  This  allows  us  to  restrict  the  range 
of  junk,  and  the  introduction  of  erroneous  effects.  Consider 
our  small  lambda  calculus  example  once  again. 

datatype  Term 

=  App  Term  Term 

|  Abs  Term  =>  Term 

j  Const  Int 

Terms  of  type  a  =>  b  are  introduced  using  the  meta¬ 
language  construct  for  object-binding  introduction.  The 
expression  level  syntax  of  the  met  a- language,  is  analogous 
to  the  syntax  of  the  type  constructor  for  object- level  bind¬ 
ings.  For  example:  (#x  =>  App (#x, Const  0))  ::  (Term 
=>  Term).  Here  we  use  the  hash  (#x)  notation  to  distin¬ 
guish  object-level  variables  from  meta-level  variables.  An 
important  property  of  object-variables,  is  that  they  can¬ 
not  escape  their  scope.  Like  meta-level  function  binding, 
object-binding  respects  static  scoping.  The  =>  introduction 
construct  (#x  =>  e)  delimits  the  scope  of  #x  to  e.  The  key 
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property  of  object-binding  is  that  evaluation  proceeds  under 
=>. 

Below  are  two  different  examples  of  constructing  an  object- 
language  program.  The  first  using  meta-level  functions  as 
the  binding  mechanism,  and  the  second  using  object-level 
abstraction: 

Abs’(\x  ->  bottom)  Abs(#x  =>  bottom) 

The  expression  on  the  left  uses  a  meta-language  bind¬ 
ing  mechanism  (A  abstraction).  It  succeeds  in  constructing 
a  representation  of  an  object-language  program  which  obvi¬ 
ously  has  no  meaning.  The  expression  on  the  right,  however, 
does  not  represent  any  object-language  program,  since  the 
expression  never  terminates.  Note  that  the  effect  on  the  left 
has  seeped  into  the  object-language  program  representation 
(junk),  while  on  the  right  non-termination  occurs  before  the 
object-language  program  is  constructed  and  thus  is  never 
present  in  the  object-language  program  itself. 

A  more  sophisticated  example  is  the  copy  function  over 
Term 

copy  (App  f  x)  =  App  (copy  f)  (copy  y) 
copy  (Const  n)  =  Const  n 

copy  (Abs(#x  =>  e’  #x))  =  Abs(#y  =>  (copy  (e*  #y))) 
copy  (x  Q  #_)  =  x 

To  those  familiar  with  functional  programming,  the  first 
two  clauses  should  be  clear.  The  third  clause,  uses  the 
higher-order  pattern  matching  introduced  earlier,  only  ap¬ 
plied  here  in  the  context  of  the  new  object-level  binding 
construct.  Since  evaluation  passes  under  =>  diverging  com¬ 
putations  will  not  delayed. 

The  fourth  clause  of  the  copy  function  is  an  artifact  of 
the  object-level  binding  mechanism.  Object-variables  (#x) 
introduced  using  the  object-binding  syntax:  (#x  ->  .  .  . ) , 
are  a  new  type  of  constant.  The  actual  name  of  such  a 
constant  is  not  accessible  to  the  programmer.  There  are  two 
operations  that  are  necessary  on  object- variables,  it  should 
be  possible  to  distinguish  them  from  other  object-terms,  and 
it  should  be  possible  to  compare  them  using  equality,  in 
order  to  tell  them  apart. 

Thus,  functions  over  object-languages,  must  have  a  clause 
for  object-bound  variables.  Object-bound  variables  are  dis¬ 
tinct  from  all  other  constructors,  and  are  common  to  all 
object-languages.  The  pattern  #_  matches  any  object-variable, 
but  fails  to  match  other  constructors.  The  binding  says 
nothing  about  the  name  of  the  variable  it  binds  to.  The  no¬ 
tation  (x  <3  #_)  introduces  a  meta-level  variable  x,  bound 
to  the  object-level  variable  matched  by  the  object-pattern 

3.4  Expressivity 

It  is  sometimes  necessary  to  eliminate  object-bound  vari¬ 
ables.  This  is  done  in  one  of  two  ways.  First  by  applying 
a  higher-order  pattern  variable  to  some  value  x  : :  Term, 
the  occurrences  of  the  bound  variable  will  be  replaced  with 
x. 

This  is  not  always  sufficient  since  it  does  not  provide  any 
way  of  transforming  a  object-binding  into  anything  other 
than  another  object-binding.  This  was  the  problem  with 
the  show  function  (Section  3).  This  is  why  HOAS  using 


meta-level  function  binding  cannot  express  some  functions. 
Object-level  binding  allows  us  to  solve  this  problem. 

The  solution  is  a  new  language  construct  discharge.  The 
construct  (discharge  #x  =>  el)  introduces  a  new  object- 
level  variable  (#x) ,  whose  scope  is  the  body  el.  The  value  of 
the  discharge  construct  is  its  body  el.  The  body  el  can  have 
any  ground  type,  unlike  an  object-level  binding  (#x  =>  e2) , 
where  e2  must  be  an  object  term. 

In  addition,  discharge  incurs  an  obligation  that  the  object 
variable  (#x)  does  not  appear  in  the  value  of  the  body  (el) . 
An  implementation  must  raise  an  error  if  this  occurs. 

For  example  consider  a  function  which  counts  the  number 
of  Const  subterms  in  a  Term. 

count  : :  Term  ->  Int 
count  (Const  _)  =  1 

count  (App  f  x)  =  (count  f)  +  (count  x) 
count  (Abs(#x  =>  e ’  #x))  = 

discharge  #y  =>  count  ( e’  #y) 
count  #_  =  0 

Note  how  that  the  fourth  clause  conveniently  replaces  all 
introduced  object-bound  variables  with  0,  thus  guaranteeing 
that  no  object- variable  appears  in  the  result.  The  obligation 
that  the  variable  does  not  escape  the  body  of  the  discharge 
construct  may  require  a  run-time  check  (though  in  this  ex¬ 
ample,  since  the  result  has  type  Int,  no  such  occurrence  can 
happen). 

If  a  programmer  needs  to  treat  individual  object-bound 
variables  in  different  ways,  he  can  use  an  environment  pa¬ 
rameter.  Consider  the  program  below,  which  is  the  correct 
implementation  of  the  function  show. 

show  x  =  sh  n  []  x 
where 

sh  n  (App  f  x)  =  (sh  n  f)  ++  "  "  ++  (sh  n  x) 
sh  n  (Const  n)  =  toString  n 
sh  n  (x  @  #_)  =  lookup  x  n 
sh  n  (Abs(#y  =>  f  #y))  = 
let  x  =  len  n 

v  =  x  ++  (toString  x) 
in  discharge  #x  => 

"\\  "++  v  ++  "  ->  " 

++  (show  ((#x,v):n)  (f  #x)) 

Here  the  environment  n  is  a  list  of  pairs  mapping  object- 
variables  to  strings.  If  the  sh  function  is  applied  to  an 
object- variable  it  looks  up  its  name  in  the  environment.  For 
an  object-abstraction,  (Abs  *  (#x  =>  f  #x) ) ,  discharge  in¬ 
troduces  a  new  object- variable,  adds  it  to  the  environment, 
and  then  applies  the  higher-order  pattern  variable  f  to  the 
introduced  variable,  and  recursively  produces  a  string  as  the 
representation  of  the  abstraction’s  body. 

Another  example  transforms  a  Term  into  its  de  Bruijn 
equivalent  form. 

data  DB 

=  DApp  DB  DB 
I  DAbs  DB 
|  DVar  Int 
j  DConst  Int 

DeBruijn  env  (App  f  x)  = 

DApp  (DeBruijn  env  f)  (DeBruijn  env  x) 
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DeBruijn  env  (Abs(#x  =>  e’  #x))  = 

discharge  #y  =>  DAbs (DeBruijn  (ext  env  #y)(e’  #y)) 
where  ext  env  v  u  = 

if  v=u  then  0  else  1  +  (env  u) 

DeBruijn  env  (Const  n)  =  DConst  n 
DeBruijn  env  (z  0  #_)  -  env  z 


4.  EXAMPLES 

In  this  section  we  use  our  language  to  express  some  classic 
manipulations  on  object-languages. 


•  Lambda  calculus  syntax 

datatype  Lterm  =  App  Lterm  Lterm 

I  Abs  Lterm  =>  Lterm 
|  Const  Int 
I  Prod  Lterm  Lterm 

•  Call-by-name  Big-step  evaluator  for  untyped  lambda 
calculus: 

eval  :  Lterm  ->  Lterm 
eval  (Abs  body)  =  Abs  body 
eval  (App  tl  t2)= 
case  eval  tl  of 

(Abs  (#x  =>  body  #x))  ->  eval  (body  t2) 
eval  (Const  n)  =  Const  n 
eval  (Prod  x  y)  =  Prod  (eval  x)  (eval  y) 
eval  (x  0  #_)  =  x 


5.  NEW  FEATURES  OF  DalI 

The  language  DALI  contains  some  features  that  behave  in 
untraditional  ways.  It  is  useful  to  call  attention  to  these 
features. 

•  Object  variable  bindings:  Unlike  the  meta-language 
binding  construct,  the  evaluation  of  an  object-level  ab¬ 
straction  ((#x  =>  e))  proceeds  “under”  the  =>. 

•  Ground  (or  equality )  values :  such  values  can  be  com¬ 
pared  for  simple  structural  equality.  The  important 
property  of  ground  values  is  that  they  do  not  contain 
functions.  Only  ground  values  are  used  to  represent 
valid  object  languages. 

In  order  to  compare  object-language  terms  for  equality 
it  is  necessary  to  compare  object- variables  for  equal¬ 
ity.  This  must  be  a  primitive  in  the  language.  Equality 
on  object-language  types  is  important  for  twro  reasons. 
First,  it  facilitates  an  important  programming  tech¬ 
nique,  illustrated  in  our  de  Bruijn  notation  example 
above.  Second,  it  makes  possible  higher- order  pattern 
matching  (see  below). 

•  Object-variable  matching :  Comparing  object-language 
terms  for  equality  is  not  enough  for  the  meta-programs 
in  our  examples.  We  must  be  able  to  distinguish  object- 
level  variables  from  other  object-level  terms.  This  is 
the  purpose  of  the  (  #_  )  pattern. 


•  CBN  lambda  calculus  (single  step)  reduction: 

beta  :  Lterm  ->  Lterm  **>  Lterm 

beta  (Abs  (#z  =>  body  #z))  t2  =  body  t2 

•  Complete  development: 

compdev  :  Lterm  ->  Lterm 
compdev  (Abs(x#  =>  body  #x)) 

=  Abs(#w  =>  compdev  (body  # w)) 
compdev  (App  (Abs(#x  =>  body  #x))  y) 

=  sub  (Abs(#w  =>  compdev (body  #w)))  (compdev  y) 
where  sub  (Abs(#z  =>  e  # z))  x  =  e  x 
compdev  (App  f  x)  =  App (compdev  f ) (compdev  x) 
compdev  (Prod  x  y)  =  Prod (compdev  x) (compdev  y) 
compdev  (Const  n)  =  Const  n 
compdev  (x  0  #_)  -  x 

•  Substitution  on  Lterms. 

find  x  []  -  Nothing 

find  x  ((y,v):ys)  =  if  x==y 

then  v 

else  find  x  ys 

subst:  Lterm  ->  [(Lterm, Lterm)]  ->  Lterm 
subst  x  env  - 
case  find  x  env 
Just  t  ->  t 
Nothing  -> 
case  x  of 
V  0  #_  ->  V 
Abs(#x  =>  e  #x)  -> 

Abs(#w  =>  subst  env  (e  #w)) 

App  x  y  ->  App(subst  env  x) (subst  env  y) 

Prod  x  y  ->  Prod (subst  env  x) (subst  env  y) 
Const  n  ->  Const  n 


•  Higher- order  pattern  matching:  A  higher  order  pat¬ 
tern  variable  (i.e.  x  in  (\(#z  =>  x  #z)->e)  is  bound 
to  a  (meta-level)  function  that  returns  the  body  of 
the  object-level  abstraction  after  replacing  the  object- 
variable  with  its  argument.  This  in  effects  internalizes 
substitution  for  bound  object-level  variables  in  object 
programs.  In  order  to  implement  such  a  scheme,  it 
is  important  that  the  object-abstraction  body  be  an 
equality  type.  I.e.  we  must  somehow  disallow  types 
of  the  form  (a  =>  (b  ->  c)).  If  we  do  not  do  this 
then  interesting  anomalies  may  occur.  For  example 
consider: 

f  (# z  =>  x  #z)  =  x  (Const  0) 
w  =  (#x  =>  (\  y  ->  Prod  #x  (Const  5))) 

If  we  apply  f  to  w,  we  must  build  a  meta-level  function 
x  which  replaces  all  occurrences  of  #x  in 
(\  y  ->  Prod  #x  (Const  5))  with  (Const  0).  It  is 
unlikely  we  can  do  this  if  functions  are  only  exten- 
sional. 

6.  A  NOTE  ABOUT  “DISCHARGE” 

In  defining  meta-programs,  the  use  of  discharge  is  often 
crucial,  since  it  allows  for  eliminating  an  object-level  binding 
and  performing  computations  only  on  its  body.  However, 
the  binding’s  body  can  be  safely  extracted  only  if  there  is 
a  guarantee  that  a  heretofore  bound  object-level  variable 
cannot  become  free  as  a  result  of  computation  over  its  body. 
There  are  two  ways  of  adding  discharge  to  DALI:  First,  as 
a  new  language  construct  with  appropriate  reduction  rules; 
and  second,  as  a  function  defined  by  the  user  on  a  per- 
datatype  basis. 
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In  the  present  paper,  we  opt  for  the  second  design  decision 
in  order  to  keep  the  core  calculus  of  DALI,  and  its  technical 
development  as  small  as  possible.  We  present  an  example 
of  a  user  defined  discharge  function  for  the  lambda-term 
datatype  (Lterm): 

discharge  (#w  =>  t  #w)  = 

case  (#a  =>  find  #a  (t  #a))  of 
(#z  =>  True  )  ->  t  () 

(# z  =>  False)  ->  diverge 

find  var  (App  tl  t2)  = 

(find  var  tl)  or  (find  var  t2) 
find  var  (Abs(#w=>b  #w))  = 

case  (#z  =>  find  var  (b  #z))  of 
(#z  =>  True  )  ->  True 

(#z  =>  False)  ->  False 
find  var  (Prod  tl  t2)  = 

(find  var  tl)  or  (find  var  t2) 
find  var  (Const  n)  =  False 
find  var  (x  <3  #_)  = 
if  x  =  var  then  True 
else  False 


The  function  discharge  simply  searches  the  body  of  an 
object-level  abstraction  for  the  abstracted  object-level  vari¬ 
able.  If  the  variable  is  not  found  in  the  body,  the  program 
simply  returns  the  body  itself.  Otherwise,  the  computation 
diverges. 

It  is  important  to  note  that  in  DALI,  discharge,  whether 
added  as  a  language  construct  or  defined  as  a  function,  can 
be  used  only  on  ground  values,  i.e.,  values  that  do  not  con¬ 
tain  suspended  computation.  Extending  discharge  to  ap¬ 
ply  to  values  that  contain  abstraction  causes  confluence  and 
soundness  problems  similar  to  those  described  in  section 
8.1. 

However,  there  appear  to  be  situations  where  such  a  more 
general  version  discharge  is  desirable.  The  example  below, 
implements  a  kind  of  evaluation  for  the  familiar  encoding  of 
untyped  lambda  terms,  using  an  environment. 

data  Value  =  Vint  Int 

1  Vprod  Value  Value 
j  Vfun  Value  ->  Value 

type  Env  =  [(Lterm  *  Value)] 

eval’  :  Env  ->  Lterm  ->  Value 
eval’  env  (Abs  (#x  =>  b  #x) )  = 
discharge  #w  => 

Vfun(\  y  ->  eval*  (extend  #x  y  env)  (b  #w)) 
eval’  env  (App  tl  t2)  = 
case  eval’  env  tl  of 

Vfun  f  ->  f  (eval*  env  t2) 
eval’  env  (Const  n)  =  Vint  n 
eval’  env  (Prod  x  y) 

=  Prod(evalJ  env  x)(eval*  env  y) 
eval’  env  (x  @  #_)  =  env  x 

In  the  present  version  of  the  language  it  is  impossible  do 
define  a  discharge  function  needed  for  the  second  clause 
of  eval  * ,  since  it  would  involve  detection  of  free  object- 
bound  variables  in  a  term  that  contains  an  (extensional) 
meta-level  function.  On  the  other  hand,  the  example  is  in¬ 
tuitively  correct,  and  one  can  convincingly  argue  from  the 


definition  of  the  function  eval  ’  that  the  discharged  object- 
level  variables  indeed  never  do  appear  in  the  values  of  eval  * . 
Whether  an  appropriate  mechanism  can  be  introduced  to  ex¬ 
tend  discharge  to  such  cases  remains  a  question  yet  to  be 
fully  addressed  for  DALI. 

7.  FORMAL  SEMANTICS  OF  CORE  DALI 

7.1  Syntax 

Figure  1  defines  the  various  syntactic  categories  used  in  spec¬ 
ifying  Core  DALI,  including  expressions  E,  ground  values  B, 
values  V,  and  contexts  C. 

Expressions  in  Core  DALI  include  the  lambda  calculus 
with  naturals.  Further,  the  language  incorporates  datatypes 
(not  necessarily  just  first-order),  in  addition  to  the  following 
specialized  mechanisms: 

•  Object-level  variables  #z  and  binders  (#z  =>  e), 

•  Pattern  matching  over  object-bindings  \{#z  =>  x).e. 

•  Equality  for  object-bound  variables  =#  #z 

•  Test  of  whether  an  expression  evaluates  to  an  object- 
level  variable  (isOVar  e). 

Values,  ground  values,  and  context  are  used  in  defining  the 
reduction  semantics. 

7.2  Core  DALI  vs.  Example  Language 

The  Core  DALI  has  two  (more  primitive)  forms  of  pattern 
matching  than  the  language  used  in  the  examples:  one  for 
tagged  values,  one  for  object-level  bindings.  A  third  form  of 
pattern  matching  (for  object-level  variables)  can  be  easily 
encoded  using  isOVar . 

Nested  patterns  are  not  allowed,  nor  are  more  complicated 
higher-order  patterns  directly  supported:  each  constructor 
has  one  argument,  and  each  higher-order  pattern  variable 
has  exactly  one  possible  free  object  variable  in  it.  These 
simplifications  make  the  formal  development  of  Core  DALI 
more  manageable,  without  losing  generality:  programs  in  a 
more  familiar  language  of  our  examples  can  be  translated 
into  equivalent,  albeit  more  verbose  Core  DALI  expressions. 

7.3  Big  Step  Semantics  (ad) 

Figure  2  defines  the  call-by- value  (CBV)  big-step  semantics 
for  Core  DALI.  Note  that  this  semantics  does  not  require  a 
gensym  function  or  any  freshness  conditions  on  variables: 
All  necessary  variable  renaming  is  handled  by  two  stan¬ 
dard  notions  of  substitution  [2],  one  for  object-level  variables 
(#z  £  Z)  and  one  for  meta-level  variables  (r  G  X). 

7.4  Reduction  Semantics  (Arf) 

Figure  1  defines  the  reduction  semantics  for  Core  DALI. 

8.  SUMMARY  OF  TECHNICAL  DEVELOP¬ 
MENT 

The  main  technical  result  of  our  work  to  date  is  establish¬ 
ing  the  confluence  property  for  the  reduction  semantics  de¬ 
scribed  above,  and  establishing  (the  rather  non-trivial  con¬ 
nection)  between  the  reduction  semantics  and  big-step  se¬ 
mantics.  In  doing  so,  we  have  following  closely  Taha’s  de¬ 
velopment  for  the  (substantially  smaller)  language  A  —  U 
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Syntax: 


xex 

Normal  variables  := 

z  G  Z 

Object  variables  := 

/E  F 

Tags  := 

F  CF 

Tag  sets  = 

e  G  E 

Expressions  := 

CeC 

Contexts  := 

be  B 

Ground  Values 

:= 

v  G  V 

Values 

:= 

p  G  R 

Reductions 

:= 

Infinite  set  of  names 
Infinite  set  of  names 

Infinite  set  of  names  containing  True  and  False 
Finite  subsets  of  F 

()|*|  Xx.e  |  e  e  \  (e,e)  |  7n  e  |  tt2  e  |  /  e  |  A  f€F(f  */).e/  | 
#z\#z=>e\  X (#z  =>  x).e  |  isOVar  e  |  e  =#  e 
0  |  A  x.C  \Ce\eC\(e,C)\(C)e)\ir1C\ir2C\ 

A /€**-{/'}((/,.  *0.ci)  +  +(/'  *).C  |  /  C  |  (#*  =»  C)  |  A(#*  =>  *).C  | 
isOVar  C  \  C  =#  e  |  e  =#  C 
{)  \  {b,b)  \  f  b  \  #z  \  #z=>b 

0  I  Ax.e  |  (v,v)  |  /  «  |  A/€F/  s/.e/  |  #z  \  #2  =>  «  |  A(#2  =>  x).e 

(Sl  |  7Tl  |  7T2  I  ft  I  /?3  |  #  |  ^isOVar 


Notions  of  Reduction: 


(Ax.e)  v  — ¥p1 

7T1  (ui,u2)  — 

n2  (vi,v2)  >ir2 

(A /€FU{*}(y  £/).e/)  (fc  v)  - ^ 

(A(#z'  =>  x).e)  (#2  =>  b)  — >/33 

#2  =#  #2  ># 

#21  =#  #22  ># 

isOVar  #2  >isOVar 

isOVar  u  — >i$ovar 


e[x  :=  u] 

V\ 

v2 

ek\xk  :=  u] 

e[x  :=  \y.{b[#z  :=  y])] 
True() 

False()  if  zi  7^  z2 
True() 

FalseQ  if  v  /  #z 


Reduction  Semantics: 


e\  62 
C[e,]  — *  C[e/ 


e  R 


ei 


•  e2  e2 


e3 


Cl 


e3 


Figure  1:  Syntax  and  Reduction  Semantics  (Arf)  of  Core  DALI 


[45;  47].  Taha’s  development  is  based  on  Takahashi  parallel 
reduction  and  complete  development  methods  for  proving 
confluence  [52],  and  Plotkin’s  “standardization”  technique 
for  showing  that  reductions  preserve  observational  equiva¬ 
lence. 

This  section  summarizes  our  technical  development  and 
states  our  main  result,  and  explains  how  they  were  useful 
to  us  in  the  process  of  designing  the  semantics  for  DALI. 
The  full  details  cannot  be  included  in  this  paper,  and  are 
presented  instead  in  a  technical  report  available  on-line  [36, 
40  pages]. 

8.1  Confluence 

The  first  result  is  confluence: 

Theorem  1  (Xd  Is  Confluent).  Vei,e2,e  E  E. 
ei*  i —  e  — >*  e2  ==>  ( Be '  E  E.  e\  — ¥*  e*  < —  e2) 

First,  we  are  not  aware  of  a  similar  proof  for  a  language  with 
datatypes.  Furthermore,  this  result  establishes  the  existence 
of  a  confluent  calculus  for  a  language  with  notion  of  object- 
level  binders,  and  analysis  on  these  terms.  In  particular, 
this  result  means  that  DALI  also  provides  a  solution  to  the 
problem  of  introducing  intensional  analysis  to  MetaML  in  a 
“coherent”  manner  [47]. 

8.1.1  Role  in  Design  ofDALl 


In  addition  to  its  technical  role  in  arriving  at  our  next  re¬ 
sult,  establishing  the  confluence  property  played  an  impor¬ 
tant  role  in  our  design  process:  It  drew  our  attention  to  the 
need  for  introducing  the  notion  of  ground- values,  thereby 
prohibiting  any  useful  mixing  of  object-binder  and  function 
spaces  in  datatypes. 

In  particular,  analysis  over  object-level  binders  (/33  re¬ 
duction)  without  the  restriction  of  the  argument  to  ground 
values  breaks  the  confluence,  as  is  illustrated  in  the  following 
example: 

Suppose  the  notion  of  reduction  — >p3  (Figure  1)  were 
defined  as  follows  (we  emphasize  the  part  different  from  the 
standard  definition  by  placing  it  into  a  box): 


(X {#z'  =»  x).e)  [#z  =>  v) 


— >03  e[r  :=  A y.v[#z  :=  y]] 


Now,  consider  the  function  /  =  (A(#w  =>  x).x  (A u.u)). 
This  function  takes  an  object-level  binding  as  its  argument 
and  returns  the  body  of  the  binding  in  which  the  object- 
bound  variable  has  been  replaced  with  the  identity  function 
A  u.u.  For  the  application  of  /  to  the  object  binding  (#£  => 
(A y.#z  =  #2)),  there  are  two  possible  reduction  sequences: 

/  (#z  =>  (Ay.#2  =  #2))  — >t?3  Ay.(Au.u)  =  (Xu.u) 

and 

/  (#2  =>  (Ay. #2  =  #2))  — >#  f  (#2  =>  (Ay.True())) 
— >03  Ay.True() 

Clearly,  neither  Ay.TrueQ,  nor  Xy.(Xu.u)  =  (Au.w)  can  be 
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e\  4  Ax.e  ei  4  A/eFuW(/ x/).e/ 

62  4  ez  e2  4  k  e\ 

e[x  :=  63]  4  e4  efc[r  e^]  4  es 
0  *-4  ()  Arr.e  4  \x.e  e\  e2  4  6\  ex  62  4  e5 


e\  4  A (#z*  =>  x).e 
e2  4  #z  =>  63 
e[x  :=  Ax'.(£>3[#2  :=  a:'])]  <-4 
ei  e2  4  e4 


d  4  e3  62  ^4  e4 

(ei,e2)  4  (e3,e4) 


e  *-4  (e3?e4)  e  4  (e3,e4) 
7Ti  6  1 — f  63  7T2  e  4  e4 


ei  4  e2 

/*  Cl  *-4  fk  e2  \feFf  Xf.ej  *-4  A’Gi7  x/.e/ 


ei  4  e2 

#z  4  #z  #z  =>ei  4  #2  =>  e2 


A(^  =s>  x).e  *-4  A(z  =>•  z).e 


ci  «4 
62  4  #Z 

ei  =#  e2  4  TrueQ 


ei  4  #21 

e2  4  #Z2  Jgi  ^  2:2 

ex  —  #  e2  *-4  False() 


e  <4  #z  e  4  u  v  ^  -#z 

isOVar  e  4  True()  isOVar  e  4  Fa!se() 


Figure  2:  Big-Step  Semantics  (AD)  of  Core  DALI 


further  reduced  by  \d  to  a  common  reduct:  a  clear  coun¬ 
terexample  for  confluence. 

Finally,  note  that  the  breakdown  of  confluence  here  pro¬ 
vides  a  concrete  illustration  of  one  of  the  wide  range  of  diffi¬ 
culties  that  can  arise  from  mixing  function  spaces  with  “syn¬ 
tax”  .  Other  examples,  such  as  the  discussion  of  “covers”  in 
the  context  of  MetaML  implementation  [45]  require  much 
more  infrastructure  to  present. 

8.2  Soundness 

We  will  consider  two  programs  to  be  equivalent  when  they 
can  be  interchanged  in  any  context  without  affecting  the 
termination  (or  non-termination)  of  the  full  term  in  which 
they  occur.  This  is  known  as  observational  (or  contextual) 
equivalence,  and  is  defined  as  follows: 

Definition  2  (Observational  Equivalence).  We  write 
e\  &  62  if  and  only  if 

VC  €  C.  (3v  e  V.  C[ei]  4  v)  <=>  (3v  €  V.  C[e2]  4  v) 

Our  soundness  result  can  now  be  stated  as  simply: 

Theorem  3  (Soundness). 

Vei,e2  €  E.e \  — >  e2  ==>  ei  ss  e2 

First,  our  proof  for  this  theorem  is  the  first  operational  ac¬ 
count  known  to  us  where  the  soundness  of  such  reductions 
for  an  untyped  CBV  functional  language  with  datatypes  is 
established  (Using  bisimilarity  techniques,  Pitts  does  present 
a  similar  result,  but  for  a  typed  CBN  language  supporting 
binary  sum  types  [41].) 

Second,  the  soundness  of  these  results  establishes  that 
extending  the  lambda  calculus  plus  datatypes  with  DALl’s 
constructs  for  introducing  and  analyzing  object-level  binders 
and  free  variables  at  runtime  does  not  injure  the  notion  of 
observational  equivalence  in  a  devastating  way.  Certainly, 
it  may  very  well  be  that  introducing  the  new  constructs 
allows  us  to  distinguish  between  more  terms  in  the  language 
(as  does  introducing  exceptions,  for  example),  and  this  is  a 
question  for  future  work. 


8.2.1  Role  in  Design  o/DalI 

The  immediate  technical  benefit  of  this  result  is  providing 
technical  justification  for  using  the  reductions  as  semantics¬ 
preserving  optimizations  in  an  implementation.  But  there 
are  other  benefits  that  we  are  interested  in  from  the  point 
of  view  of  language  design: 

1.  It  provides  us  with  a  basic  understanding  of  the  no¬ 
tion  of  observational  equivalence.  In  particular,  in  the 
case  of  this  language  (as  is  in  the  case  for  many  deter¬ 
ministic  languages),  one  arrives  at  a  simple  equational 
theory  simply  be  changing  reduction  arrows  into  “con¬ 
vertibility”  equalities. 

2.  Taha’s  development  [45;  47]  emphasizes  partitioning  ex¬ 
pressions  into  values,  workables,  and  stucks,  and  estab¬ 
lishing  “monotonicity  properties”  from  which,  for  ex¬ 
ample,  Wright  and  Felleissen’s  “Uniform  Evaluation” 
[53]  follows.  Thus,  not  only  do  we  provide  the  basis 
for  posing  the  question  of  “what  is  a  type  system  for 
datatypes  with  binder” ,  we  already  provide  some  of  the 
technical  properties  needed  in  establishing  type  safety 
for  any  type  system  that  we  may  wish  to  investigate. 

3.  Attaining  this  result  involves  constructing  a  number 
of  variations  of  the  operational  semantics,  and  relat¬ 
ing  them  formally.  This  process  provides  a  substantial 
amount  of  cross-checking  between  various  definitions, 
and  gives  a  very  accurate  operational  understanding 
of  the  kind  of  invariants  that  a  type  system  will  be 
expected  to  guarantee. 

9.  RELATED  WORK 

DALI  is  a  functional  meta-programming  language,  and  is 
related  as  such,  to  many  other  meta-systems. 

Meta-systems  built  with  a  functional  programming  base 
include  MetaML  [47;  51],  An[12]  and  A°[llj.  These  differ 
from  DALI  in  that  they  are  homogeneous  systems,  where 
the  meta-  and  object-languages  are  the  same.  None  of  these 
systems  provide  mechanisms  for  analyzing  the  structure  of 
object-programs. 
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Theorem  prover  based  meta-systems  have  been  constructed 
for  several  kinds  of  logics.  Implementations  of  classical  log¬ 
ics  include  the  HOL  [18]  theorem  prover,  Isabelle  [35],  and 
the  Prototype  Verification  System  (PVS)  [34].  Implemen¬ 
tations  of  constructive  (or  intuitionistic)  logics  include  Elf 
[37],  Coq  [10;  3],  Nuprl  [9]  and  Lego  [42]. 

Finally,  there  are  logic  programming  languages  with  meta¬ 
programming  extensions,  A-Prolog  [31;  15;  27],  and  L\  [24]. 
These  are  prolog-like  languages  with  extensions  for  repre¬ 
senting  and  analyzing  object-programs  whose  representa¬ 
tions  are  based  on  the  A-calculus. 

Of  these  systems,  Isabelle,  Elf,  A-Prolog,  and  L\  use 
some  sort  of  higher-order  abstract  syntax  to  represent  object 
terms.  Of  these,  all  but  La,  use  higher  order  unification  to 
implement  intensional  analysis  of  object  terms.  Higher  order 
unification  is  in  general  undecidable,  and  does  not  guarantee 
a  most  general  unifier. 

L\  implements  a  subset  of  lambda-Prolog,  where  inten¬ 
sional  analysis  is  syntactically  restricted  to  a  form  which  is 
decidable  using  unification  on  higher-order  patterns.  It  is 
this  idea  transferred  to  the  functional  programming  world 
that  is  the  basis  for  ML\  and  DALI. 

The  term  higher- order  abstract  syntax  was  originated  by 
Pfenning  and  Elliott  [38].  This  work  provided  a  basis  for  au¬ 
tomating  reasoning  in  LF[19],  and  was  used  as  the  basis  for 
the  implementation  of  Pfenning’s  Elf[37]  and  its  successor 
Twelf  [40] . 

9.1  DalI  vs.  MLa 

Dale  Miller  [23]  describes  MLa,  a  proposal  to  extend  ML 
to  handle  bound  variables  in  data- types.  The  idea  of  repre¬ 
senting  object-level  bindings,  in  a  functional  language,  using 
a  binding  construct  different  from  the  function  abstraction 
of  the  meta-language  derives  from  this  paper.  While  our 
work  takes  Miller’s  proposed  extensions  as  its  basis,  there 
are  some  differences: 

•  We  distill  the  main  ideas  of  Miller’s  MLa  into  a  basic 
calculus  of  core  DALI.  We  concentrate  on  the  the 
reduction  semantics  and  equational  theories  of  such 
a  language.  To  the  authors’  knowledge,  this  work  is 
the  first  instance  of  a  sound  reduction  semantics  for  a 
functional  language  supporting  binding  constructs  in 
data-types. 

•  We  abandon  the  notion  of  function  extension  that  al¬ 
lows  extending  the  domain  of  arbitrary  ML  functions 
within  the  scope  of  an  object-level  variable.  We  find 
function  extension  needlessly  difficult  to  model  in  a  re¬ 
duction  system,  and  seek  to  introduce  an  alternative 
construct:  patterns  that  match  object-level  variables. 
We  conjecture  that,  together  with  equality  over  object- 
level  variables,  one  can  circumvent  function  extension 
without  loss  of  expressiveness  or  good  programming 
style. 

•  We  abandon  the  notion  of  object-level  application  [23]. 
Rather,  pattern  matching  on  object-level  bindings  binds 
higher-order  pattern  variables  to  functions  that  per¬ 
form  appropriate  substitutions  directly,  thus  further 
simplifying  formal  development,  and,  in  practical  terms, 


internalizing  object-level  variable  substitution,  which 
in  [23]  must  be  defined  separately  for  each  data-type. 

However,  internalization  of  such  object-level  substitu¬ 
tion  in  presence  of  extensional  function  values  is  not 
without  cost:  we  had  to  resort  to  a  fine  distinction  be¬ 
tween  ground  (or  equality)  values  and  the  more  stan¬ 
dard  notion  of  values  in  such  calculi,  and  adjust  eval¬ 
uation  and  reduction  to  restrict  the  analysis  of  object- 
language  terms  to  preserve  soundness  and  confluence 
of  the  calculus. 

DALI  differs  from  most  of  the  other  work  discussed  above 
in  following  ways: 

•  It  is  functional  and  deterministic,  and  is  presented  as 
an  extension  of  a  standard  CBV  functional  language. 
It  provides  support  for  higher-order  syntax  by  provid¬ 
ing  a  small  number  of  new  language  constructs. 

•  The  formal  properties  we  have  proven  about  the  lan¬ 
guage  suggest  that  the  new  features  integrate  well  with 
the  host  functional  language. 

•  The  reduction  semantics  we  provide  gives  rise  to  a  sim¬ 
ple  equational  theory  that  can  be  used  to  reason  about 
program  equivalence. 

10.  CONCLUSIONS  AND  FUTURE  WORK 

In  this  paper  we  have  shown  that  a  functional  program¬ 
ming  language  with  support  for  higher  order  abstract  syn¬ 
tax  through  an  additional  ob  ject-level  binding  construct  can 
be  assigned  a  simple  big-step  semantics.  We  have  defined 
a  reduction  semantics  and  presented  important  results  of 
confluence  and  soundness  w.r.t.  evaluation  of  this  reduction 
semantics  for  DALI.  After  this  initial  success  much  work 
remains  to  be  done.  In  particular: 

•  Developing  a  basic  type  system  for  DALI.  In  addition 
to  the  traditional  notions  of  safety  there  are  some  ef¬ 
ficiency  concerns  that  we  expect  that  a  type  system 
could  be  used  to  alleviate.  In  particular,  the  discharge 
operation  and  the  use  of  the  ground-value  restriction 
b  in  the  semantics  would  incur  significant  run-time 
penalties  in  an  implementation.  We  expect  that  an 
appropriate  type  system  could  help  avoid  these. 

•  Integrating  with  multi-stage  programming.  In  partic¬ 
ular,  DALI  meta-programming  utility  is  orthogonal  to 
that  of  multi-stage  programming  [49;  48;  48;  29;  4]: 
with  DALI,  the  object  language  is  allowed  to  vary,  and 
intensional  analysis  is  supported.  Note,  however,  that 
DALI  does  support  the  hygienic  synthesis  of  object 
code,  although  in  a  manner  less  concise  than  those  of 
multi-stage  programming  languages.  Finally,  whereas 
it  has  been  demonstrated  that  the  former  can  guaran¬ 
tee  that  the  synthesized  code  is  type  correct,  the  only 
guarantee  that  we  have  at  the  moment  with  DALI  is 
that  the  synthesized  code  is  syntactically  correct. 

•  An  implementation  of  a  full  programming  language  en¬ 
vironment  based  on  DALI.  Although  a  full  implemen¬ 
tation  of  DALI  is  missing  at  the  moment,  the  mech¬ 
anisms  of  higher-order  pattern  matching  and  analysis 
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of  object-level  bindings  has  been  implemented  by  Tim 
Shear d  as  an  experimental  feature  of  the  MetaML  in¬ 
terpreter  [43]. 

From  the  point  of  view  of  semantic  language  design,  in 
reproducing  Taha’s  technical  development  of  MetaML,  we 
have  found  that  all  the  proofs  could  be  carried  out  in  a 
systematic  manner  for  the  (considerably  larger)  language 
at  hand,  and  that  many  of  the  proofs  remain  literally  un¬ 
changed.  This  seems  to  be  primarily  due  to  the  use  of  the 
notion  of  “workables”  in  parameterizing  the  various  lem¬ 
mata.  In  future  work,  we  intend  to  investigate  the  extent  to 
which  this  development  can  be  generalized. 
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APPENDIX  C 


DalI:  An  Untyped  CBV  Operational 
for  Datatypes  with  Binders 


Semantics  and  Equational  Theory 
(Technical  Development) 


Emir  Pasalic,  Tim  Sheard*,  Walid  Taha** 

Oregon  Graduate  Institute  and  Chalmers  University  of  Technology 


Abstract.  This  report  presents  the  basic  definitions  and  formal  development  of  DALI,  a  novel  extension  of  the 
CBV  lambda  calculus.  DALI  is  based  on  a  proposal  by  Miller,  and  provides  an  elegant  and  well-behaved  notion 
of  object- variables.  The  notion  is  elegant  because  it  avoids  any  explicit  need  for  a  “gensym”  or  “newname” 
operation  that  is  often  needed  in  such  systems.  The  notion  is  well-behaved  in  that  it  induces  a  computationally 
adequate  equational  theory. 

Our  development  follows  the  one  employed  in  Taha’s  thesis  [4]  for  MetaML[7,  5].  The  development  was  easy 
to  adapt,  and  some  of  the  major  lemmas  and  proofs  remained  essentially  unchanged.  This  success  is  further 
evidence  of  the  robustness  of  both  the  observations  of  Talcahashi  on  the  notion  of  parallel  reduction  and  the 
original  “standardisation”  development  by  Plotkin  for  the  CBV  and  CBN  lambda  calculus. 
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1  Preliminaries 


1 


1.1  A  Note  Regarding  the  First  Revision 

This  document  presents  the  technical  development  of  a  core  calculus  of  DALI,  a  CBV  language  which  provides 
support  for  datatypes  with  bindings.  The  proofs  are  given  in  as  much  detail  as  the  space  would  allow  it. 

Due  to  the  time  constraints,  many  typographical  and  stylistic  changes  we  wished  to  make  in  order  to  make 
the  document  more  readable  and  compact  are  still  missing.  We  intend  to  address  these  problems  regarding  our 
presentation  in  a  forthcoming  revision,  e.p. 

The  document  is  organized  as  follows:  Section  2  presents  definitions  of  the  various  notions  that  will  be  used 
throughtout  the  proof.  Section  3  proves  various  basic  properties  of  those  notions.  Section  4  provides  the  general  proof 
of  confluence,  taken  directly  from  [5].  Section  5  proves  necessary  lemmas  for  DALI  that  are  required  for  the  general 
argument  in  section  4.  Section  6  gives  a  general  argument  for  soundness  of  DALI,  adapted  directly  from  [5].  Section 
7  provides  proofs  for  DALI-specific  lemmas  required  in  Section  6. 


1.2  Notes  on  the  Technical  Development 

The  development  proceeds  in  a  number  of  steps.  Some  of  these  steps  introduce  auxiliary  constructs  that  are  useful  in 
constructing  the  proofs  of  properties  in  which  we  are  interested.  These  constructs  include  well-known  notions,  such 
as  complete  development  and  parallel  reduction,  which  are  recast  in  the  setting  of  DALI. 

Each  new  notion  usually  has  certain  basic  properties  associated  with  it,  about  which  we  prove  lemmas  (Section 
3).  These  basic  properties,  beside  being  useful  in  latter  proofs,  also  ensure  that  the  definitions  of  various  notions  are 
sensible  and  correspond  to  their  equivalents  in  more  well-known  calculi. 

We  introduce  a  big-step  semantics  (or  evaluation  function  where  the  order  of  evaluation  of  subterms  is  determin¬ 
istic),  and  a  reduction  semantics  (where  the  order  in  which  the  rules  are  applied  is  immaterial). 

The  main  result  of  this  paper  is  that  reduction  preserves  evalaution.  That  is,  applying  any  sequence  of  reduction 
rules  to  a  term  does  not  change  the  value  to  which  it  evaluates.  Thus  the  reduction  calculus  can  be  used  to  transform 
one  program  into  another  program  with  equivalent  meaning. 

Our  development  includes  the  following  steps: 

-  We  define  a  core  language  (DALI,  Section  2)  that  exhibits  only  the  essential  features  and  properties  we  wish  to 
develop  theoretically. 

We  define  a  big-step  semantics  (<-*),  a  deterministic  partial  function  that  defines  the  notion  of  evaluation  of  DALI 
programs. 

-  We  define  a  reduction  semantics  (Ad),  based  on  primitive  notions  of  reduction  (e.g.,  /?),  lifted  into  arbitrary 
contexts  to  obtain  a  compatible  reduction  relation  ( — »),as  well  as  its  reflexive  transitive  closure  ( — >*). 

-  We  define  parallel  reduction (^),  for  DALI,  a  relation  between  terms  that  allows  multiple  reductions  to  be  per¬ 
formed  at  the  same  time,  nondeterministically. 

-  We  define  left  reduction (i — >-),  a  function  on  terms  that  performs  the  work  of  big-step  semantics  in  a  number  of 
small  steps. 

-  We  prove  important  properties  of  these  constructs: 

1.  Xd  is  equivalent  to  parallel  reduction.  This  allows  us  to  replace  reduction  semantics  with  parallel  reductions 
in  our  proofs,  since  parallel  reduction  is  considerably  less  dificult  to  reason  about  than  \d . 

2.  We  prove  equivalence  of  the  transitive  closure  of  left  reduction  (i — >*)  and  big-step  evaluation.  Similarly 
to  parallel  reduction,  this  allows  us  to  reason  about  i — »*  instead  of  in  our  proofs  which  simplifies  the 
development. 

-  The  first  major  result  of  our  work  on  DALI  is  the  proof  of  confluence  of  \d .  (Sections  4  and  5)  We  prove  that 
parallel  reduction  is  confluent,  which  by  equivalence  of  the  transitive  closures  of  Xd  and  parallel  reduction  allows 
us  to  conclude  that  Xd  is  confluent  as  well. 

-  Based  on  Tafia’s  soundness  proof  of  MetaML  [5],  the  partiality  of  left  reduction  function  induces  a  partitioning 
of  the  set  of  expressions,  called  expression  classes.  The  three  term  classes  are  inductively  defined  and  are  called 
values ,  workables ,  and  stucks. 

1.  Workables  are  expressions  on  which  left  reduction  is  defined,  i.e.,  can  be  advanced  by  left  reduction.  In  other 
words,  workables  may  left- reduce,  in  one  or  more  steps,  to  either  values,  stucks  or  other  workables. 
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2.  Values  are  expressions  to  which  workables  may  left- reduce  in  one  or  more  steps  but  on  which  left  reduction 
cannot  proceed  further.  They  correspond  exactly  to  the  set  of  values  defined  in  Section  2. 

3.  Stacks  are  expressions  that  cannot  be  advanced  by  left  reduction,  but  are  not  values. 

-  A  further  development  is  to  prove  certain  monotonic  properties  of  parallel  reduction  with  respect  to  term  classes. 
In  particular,  values  and  stucks  can  be  only  further  reduced  to  other  values  or  stucks  respectively,  and  most 
importantly,  if  a  result  of  the  parallel  reduction  is  a  value,  it  must  have  been  obtained  either  from  another  value, 
or  from  a  workable. 

-  Finally,  the  main  result  of  this  paper,  the  soundness  of  reduction  semantics,  is  reduced  to  proving  two  goals 

1.  A  (terminating)  evaluation  of  a  term  to  a  value  implies  a  finite  sequence  of  Xd  steps  in  which  the  original 
term  reduces  to  the  same  value. 

2.  A  finite  sequence  of  reductions  of  a  term  e  to  a  value  v  implies  that  there  exists  a  value  vf  to  which  the 
original  term  evaluates,  and  which  can  be  then  reduced  in  some  finite  number  of  steps  to  the  original  value 
v. 

The  first  goal  is  not  difficult  to  prove  by  straightforard  induction.  The  second  goal,  however,  requires  several 
transformations: 

1.  Using  the  equivalence  of  evaluation  and  left  reduction’s  reflexive  transitive  closure,  and  the  equivalence  of  Xd 
and  parallel  reduction,  the  goal  is  restated  in  terms  of  left  reduction  and  parallel  reduction. 

2.  Three  important  lemmas  are  used  in  proving  this  goal:  push-back, transition  and  permutation.  These  lemmas 
allow  rearranging  of  the  order  of  left  and  parallel  reductions  in  finite  reduction  chains  until  the  goal  is  reached. 


The  formulation  of  the  soundness  proof  technique  is  most  directly  due  to  Taha’s  work  on  MetaML[4, 5].  In  proving 
soundness  of  DALI,  we  were  able  to  directly  directly  reuse  both  the  structure  and  certain  key  lemmas  of  this  proof. 
For  others,  it  was  necessary  to  re-prove  them  in  the  context  of  the  new  language,  but  their  basic  formulation  remained 
unchanged. 


2  Definitions 


2.1 


X,Z,F,  E,  C,  V,B,  W,S 


Set  Definitions 


We  will  use  a  BNF-like  notation  for  specifying  a  number  of  inductively  defined  sets  that  will  be  used  throughout 
this  report.  Two  non-standard  notations  will  be  used  for  conciseness: 


--  Lambda  terms  with  patterns  are  written  A Z1 »  (y*  Xf).ej ,  meaning,  a  sequence  of  simple  lambda 

abstractions  Xx\ .e\, ...,  Xxn.en  corresponding  to  branches  of  a  lambda  abstraction  indexed  by  the  various  tags 

/ 1 5  •  •  •  j  / n  • 

-  Set  difference  is  written  V  \  v,  meaning,  all  possible  elements  of  Y  except  the  ones  matching  the  pattern 
particular  pattern  v.  For  example,  if  N  is  the  set  of  naturals,  then  n+  1  is  a  pattern  that  matches  naturals  greater 
than  zero,  and  N  \  (n  +  1)  is  simply  the  natural  number  zero.  This  notation  allows  us  to  avoid  having  a  definition 
of  stuck  terms  §  that  is  quadratic  in  the  number  of  constructs  in  expressions  E. 


We  will  make  use  of  Barendregt’s  variable  convention,  and  state  the  set  of  bound  and  free  variables  in 
expressions  occurring  in  any  formula  or  statement  should  be  taken  by  the  reader  to  be  distinct. 
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Definition  1 


x  E  X  Normal  variables 
z  E  S  Object  variables 
feW  Tags 
F  C  F  se£s 
e  E  E  Expressions 

C  E  C  Contexts 


b  E  E  Based  Values 
v  E  V  VWues 
E  W  W^orfca6/es 


5  E  S  S tucks 


:=  Infinite  set  of  names 
;=  Infinite  set  of  names 

:  =  Infinite  set  of  names  containing  True  and  False 
=  Finite  subsets  ofW 

:=  ()  |  a:  |  Ax.e  |  e  e  |  (e,  e)  |  tti  e  |  tt2  e  |  /  e  \  A i€F{f  xj).ef  | 

|  =>  e  |  A(#z  =>  x).e  |  isOVar  e  |  e  e 

:=  D  |  Ax.C  |  Ce  |  eC  |  (e,C)  |  (C,e)  |  an  (7  |  7r2  C  \ 

£i).et)  +  +(/'  x).C  |  /  C  |  (#z  =»  C)  |  A(#2  =>  x).C 


|  isOVar  C  |  C=#  e  |  e  =#  C 

=  0  I  (M)  I  /H  #*!#*=►* 

=  ()  j  Ax.e  |  (v,  v)  |  /  w  |  A/6f  /  x/.e/  |  #z  |  #z  =>•  v  |  A(#z  =>•  x).e 
=  (Ax.e)  v  |  (A(#_  =>  x).e)  (#z  =>  6)  j  w  e  |  v  w  \  f  w  |  #z  =>  iw  | 
(ui,e)  |  (v,to)  |  7T„  U)  |  7Tn(v,l>) 

=  e  I  #z  =  U)  I  #z  =  #z' 
isOVar  v  |  isOVar  w 

|  s  e  |  v  s  |  (s,  e)  |  (v,  s)  |  rrn  s  |  nn  (V  \  («,  v))  \  f  s 


:  =  x 


(A  f  Xf.ej)  (V\/  v)  I  (#z  =>  s) 

(V\#z)  =  e  l#z  =  (V\#z)  ls  =  el#z  =  s 
(A  (#z=>x).e)(V\(#z=>b)) 

(V\  Ae)  v  where  Ae  =  Xx.e  +  \^F  f  xj.ej  +  \(#z  ^  x).e 
isOVar  5 


P  E  ffi  Reductions  :  =  /?1  |  7Ti  |  7T2  |  /?2  |  /?3  |  #  |  IsOVar 


2.2 


C  x  E  E 


Context  filling 


Definition  2 

[  ][e']  =  e'  (Ax.C)[e']  =  Ax.(C[e'])  (A#z  x.C)[e']  =  (A #z  =>  x.C[e'])  (C  e)[e']  =  C[e']  e  (e  C)[e']  =  e  C[e'\ 

(#^C)[e']  =  (#^C[e'])  (C  =#  e)[e']  =  C[e']  =  e  (e  =#  C)[e'\  =  e  =  C[e'] 

(e,  C)[e']  =  (e,  C[e'])  (C,  e)[e']  =  (C[e'],  e)  (m  C)[e'\  =  n  (C[e'])  (tt2  C)[e'}  =  tt2  (C[e'})  (f  C)[e'}  =  f  (C[e'}) 

(A /€*■-{/'}((/  *,■).«)  +  +  (/'  x).C)[e']  =  (A^-{/'}((/  *,.).*)  +  +(/'  x).C[e']) 

(isOVar  C)[e']  =  isOVar  C[e'] 


2.3 


=.]:ExXxE-4E 


and 


_[#_:=  _]:BxZxX->E 


Substitution 


Definition  3 


()[a;:=  e3]  =  () 

x[x:  =  e3]  =  e3 

—  es]  =  ,  x  ^  x* 

\xf  .e[x:  =  es]  =  Ax;.(e[^:  =  63]) 
ei  e2[a;:  =  e3]  =  (ei [x:  =  e3])  (e2[x:  =  e3]) 
(e1)e2)[x:  =  e3j  =  (ei[x:  =  e3],  e2[x:  =  e3]) 
tti  e  [x:  =  e3]  =  7Ti  (e[x:  =  e3]) 

7r2  e  [x:  =  e3j  =  rr2  (e[x:  =  e3]) 

/  ei[x:=  e3j  =  /  (ex[x:=  e3j) 
\f*F(fxf).e}[x:  =  e3}=\f*F(fx'f).(ef[x:  =  e3}) 
#z[x:=  e3]  =  #z 

#z‘  =>  e[x:  =  e3j  =  #z’  =>  (e[x:  =  e3]) 

A(#_  =>  x').e[x:  =  e3]  =  A(#_  x').(e[x:  =  e3]) 

ci  =#  e2[x:=  e3]  =  (ei[x:=  e3j)  =#  (e2[x:=  e3]) 
isOVar  e[x:  =  e3]  =  isOVar(e[x:  =  e3]) 


()[#z:  =*]  =  () 

/  6[#z:  =  x]  =  f  (b[#z:=x]) 
#z[#z:  =  x]  =  x 
#z'[#z:  =*]  =  #«', 

#z'  =►  &[#^:  =  xj  =  z'  =>  (6[#z:  =  x]) 


Remark  4  that  the  above  definition  of  substitution  uses  Barendregt}s  variable  convention ,  and  thus  no  explicit 

side- conditions  on  renaming  substitutions  over  binding  constructs  are  necessary . 
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2.4 


_:ExExE->E 


Notions  of  Reduction 


Definition  5 


(Ax\e)  v  — >(31  e[x :  =  v] 

TTl  (vi,V2)  >7Ti 
*2  (^1,^2)  ^7T2  t)2 

(A!'eL-{fc}(/  (k  v)  — >02  ek[xk:  =  e ] 

(A(#z  =>  x).e)  (#2  =>  6)  — >0,,  e[a::  =  \x.(b[#z 

#z  =#  #2  — >#  True() 

#*i  =#  #?2  — ►#  False() 


*])] 


isOVar  #2  — ^isOVar  True() 
isOVar  i;  — )-isOVar  False() 


if  z\  #  22 
tfv  £  #2 


2.5 


C  E  X  E 


and 


C  E  x  E 


Compatible  Reduction  and  the  Reduction  Relation 


Definition  6 


gj  - fr/?  e2  _  6l  - >•  ^2  ^2  - ^3 

C[ei]  — »  ^  e  — >*  e  ei  — »*  e3 


2.6  Notation 


Notation  7  (Relation  Composition)  For  any  two  relations  ©  and  we  write  a  ©  6  ©  c  as  a  shorthand  for 
(a  ©  b)  A  (b  0  c). 


2.7 


.».CExE 


Parallel  Reduction 


In  order  to  prove  the  two  key  lemmas  presented  in  this  section,  we  will  need  to  reason  by  induction  on  the  “complexity” 
of  parallel  reduction.  Thus,  we  will  use  the  following  definition  of  parallel  reduction  with  an  associated  complexity 
measure.  Where  complexity  is  not  relevant,  we  will  simply  omit  it  to  avoid  unnecessary  clutter. 


40 


2.8 


M 

-»  -:E 


E 


Parallel  Reduction  with  Complexity 


TV 

ei  >  e2 


o  » o 


0 

X  »  X 


N 


Xx.ei  \x.e2 
M 

e\  »  e2 


M  N 

ei  ^  e3  e2  ^  e 4 

M+N 

ei  62  e3  €4 


M  N 

e\  »  e3  vi  >  v2 


M+#(x,es)N+l 

(A^.e!)^!  »  e3[x:~V2} 


M  N 

ek  >  e'k  vi^>  v2 


M+#{x,e2)N+ 1 

(\(#z  =>  a?).ei)  (#2  =>  b)  >  e2[ar:  —  \x.b[#z:  =  a;] 


(A ieFfi  Xi.ei)  (fk  vx)  >  e,k[xk:-V2] 


M  N 

e\  e3  e2  64 

~  ,  M+N  ” 

(ei,e2)  >  (e2,e4) 

M 

ei  >  e2 


M 

ei  >  e2 


M 

ei  >  e2 


tv  / 
Vi  >  vi 


TV  / 
Vo  >  ^2 


M 

7ri  ei  >  7Tx  e2 
e/  >  e/ 


M 

tt2  ei  >  7r2  e2 


,  \  Ar+1  / 
TTl  (Vl,V2)  »  Vx 


/  x  TV “I-!  / 

K2(VUV2)  >  ^2 


ili  2J  IS  f 

f  t\  >  /  e2  A -leF  f  xj.e/  >  A f€Ffxf.e'{ 

_  #*1  #  #^2 

#z  -#  #z  »  True() 


A'  , 
e  »  e' 


#21  =#  #^2  »  False() 
v  +  #z 


x 


isOVar  e  isOVar  e'  isOVar  v  False() 


M 

e\  »  e2 


N 

Cl  »  e2 


u  A/  iv 

»  #*  (#2  =>  ei)  »  (#z  =>  e2)  A(#z  =>  ®).ci  »  A(#z 


TV 


M  N 

ei  >  e2  e2  >  e4 


M  +  /V 

ei  =  #  e2  e2 


z#  e4 


isOVar  >  True() 

where  #(x,e)  is  the  number  of  free  occurrences  of  the  variable  x  in  the  term  e. 


2.9 


!_:  E  — ►  E 


Complete  Development 


Definition  8 


!(Ax\e)  =  Az.!e 

{(Xx.e3)v4 

(Aiefu{fc}(/  xj.ej))  (k  v ) 
(A(#z  =>  x).e)  (#2  =>  6) 

!((Aa;.e)  u)  =  !e[x:  =!w] 

*(ei j  C2)  =  (!ei,  !c2) 

!(7Tn  e)  =  7T„  !e  e  ^  (vi,  v2) 

!(tti  (vi,  u2))  =  !vi 
!(7r2  (vi,d2))  =  !v2 
K/c)  =  /!c 

!((A-^€Fu{fc}/ Xf.e/)  (kv))  =  \ek[xk'-  =!v] 

!#z  =  #z 

K#2  =>•  e)  =  #2  ^>!e 

!((A(#z  =»  *).c)(#«  =►  6))  =  !c[*:  =  A:r'.&[#*:  =  *']] 

!(ei  =#  e2)  =  !ei  =#!e2  if e i,e2p 
!(#z  =  #0)  =  True() 

K#^i  =  #^2)  =  FalseQ  if#Zl±#z2 
!(isOVare)  =  isOVarle  ife  (jL  V 
!(isOVar#2)  =  TrueQ 
!(isOVarv)  =  False()  ife  ^  ffz 


41 


2.10 


_  E  —y  E 


Big-Step  Semantics 


Definition  9 


0  ^  0  ^  ^-e 


ei  c — y  \x .6 
e2  M*  e3 
e[:r:  =  e3]  *->  e4 
e\  e2  ^  e4 


ci  A^€F,uW(/  */)-«/ 
c  2  c — y  k  64 

ek[x:  =  e4]  4  e5 _ 

ex  e2  c— )•  e5 


ex  «->  A(#_  =>  cc).e 
e2  *-)■  =>  &3 

e[:c:  =  Aa?'.(63[#2::  =  a?'])]  <->•  e4 
t\  e2  e4 


ex  <~Jy  e3  e2  c— >  64 
(fii ,  e2)  c— ►  (e3,  e4) 


e  c— ^  (e3,  e4) 
7r  1  e  41 — y  e3 


e  *->  (e3,  e4)  ex  ^  e2 
7 r2e4e4  /*  ex  «-4  62 


\-feFf  xj.ej  ^y  Xi£Ff  xj.ej 


ey  ^  e2 

#z  ^  jfz  #z  =>  d  ^  #z  =>■  e2 


A(z  =>-  a,‘).e  A(z  =>>  a?).e 


61  ^  #z 

62  ^ 

61  =#  62  ^  True() 


61  M-  #21 

e2  4  #z2  ^1  7^  ^2 

ei  =#  e2  ^  False() 


e  ^  #z  e  <-y  v  v  ^  #2 

isOVar  e  M-  True()  isOVar  e  False() 

Remark  10  Note  that  the  use  of  b  in  the  definition  of  the  semantics  of  the  application  of  a  case  over  object-binders 
is  an  expensive  runtime  check.  However ,  we  expect  that  it  should  be  possible  to  eliminate  the  need  for  this  check  by 
an  appropriate  type  system  that  restricts  “analysable”  terms  to  base  values . 


2.11 


:  E  — y  E  Left  Reduction 


The  notion  of  left  reduction  is  intended  to  capture  precisely  the  reductions  performed  by  the  big-step  semantics,  in 
a  small-step  manner.  Note  that  the  simplicity  of  the  definition  depends  on  the  fact  that  the  partial  function  being 
defined  is  not  defined  on  values.  That  is,  we  expect  that  there  is  no  e  such  that  v  1 — y  e. 

Lemma  22  says  that  the  set  of  workables  characterises  exactly  the  set  of  terms  that  can  be  advanced  by  left 
reduction. 


Definition  11 


Cl 


ei 


ei 


7Tne'  JT!  (Vi ,  V2)  > - M>1 


(A.r.e)  v  1 — ►  e[x:  =  v]  ei  e2  1 — >  e\  e2  v  eo  i — Hie'  (ei,e2)‘ — t(ei,e2)  (v,e)  ■ — >{v,e') 


7T*> 


(vi,w2)' — »  V2  (\feLu{k)  (/  Xf).ej)  (k  v)  i — >  ek  [a:* :  =  v\  fa — >  f  e' 


#z  =>  e  i — >■  #2  =>  e' 

_ ei  i — >  ej _ 

ei  =#  e-2  i — >  e[  =#  e2 


(A (#2  =>■  a:).e)  (#27  ^  b)  i — ►  e[a*:  =  Aa ;.6[#z':  =  a;]] 


#*'  =#  e  i — >  #P  =#  e'  #z  =#  2  ' — >  True()  #z  =#  2'  > — >  False() 


isOVar  e  1 — ^  isOVar  e'  isOVar  #2  1 — >•  True()  isOVar  r;  1 — >  FalseQ 


3  Basic  Properties 

3.1  Substitution 

Lemma  12  (Basic  Properties  of  Substitution)  Ve,ei,e2  G  E. 
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1 .  x  7^  y  A  x  £  FV(e2)  => 

2.  #xjL#yA#x£FV(e2) 


e[x: —  ei][y:=  e2]  =  e[y:  =  e2][a;:  =  ei[a?:  =  e2]] 


e[#^:  =  ei][#y:=  e2]  =  e[#y:  =  e2][#:r:  =  ei[#a;:  =  e2]] 
Proof  (Lemma  12).  The  proof  easily  follows  by  structural  induction  on  the  expression  eQ. 


3.2  Parallel  Reduction 

Lemma  13  (Compatibility  of  Parallel  Reduction)  VC  G  C. Vei,e2  G  IE. 

d  e2  =>  C[ei]  C[e2] 

Proof  (Lemma.  13).  Prof  is  by  structural  induction  on  the  context  C. 

i.  DM  » DM 

C[e1]»C[e2] 

2-  n’»ft  7T  Tnr  ii  ZT  T\  7m  i' 

(Az.C)[el]  (Ax.C)[e2J 

o  A  C'[ei]»C[e2]  e»e 

3-  [].»ir  lr,  u  1  ^  ,r,  -r  ~r 

(C  e)  ei  »  (C  e)  e2 


e  »  e  C[ei]  »  C[e2] 

4.  [),»fr  7  —  7  —  — . 


5. 1 1.» fr 


(e  C)[ex]  »  (e  C)[e2] 
e  »  e  C[ex\  >  C[e2] 
(e,C)[ei]  »  (e,C)[e2] 


*.».[:] -U- 


„  A  C[e1]»C[e2]  e»e 
I  )•» IT  —  .  r  —  777  \ ,  i 


7.  n,»fr 

8.  [].»17 
9-  [  ].»  fr 

10.  n.»ft 

11.  n.»fr 

12. 

13.  i  ],» fr 

14.  [  ].»  fr 

15.  [  J.»1T 


(C,e)[ei]  »  (C,  e)[e2] 

C [ex]  »  C[e2] 

(tti  C)[ei]  »  (7Ti  C)[e2] 
C[e i]  >  C[e2] 

(tt2  C)[ei]  »  (?r2  C)[e2] 


/«•,»■[;]  Jj- 


C[e i]  »  C'[e2] 


(A/^-{/'}((/l.  ®,).ei)  ++(/'  x).C)[ei]  »  Xi).ei)  ++(/'  *).C)[e2] 

C[ci]  »  C[e2) 


,mJJ- 


[;]  U 


-.w-U- 


(/  C)[Cl]»(/  C)[e2] 

C[ei]  >  C[e 2] 

(#*  =>  C)[ei]  »  (#*=*  C)[e2] 

_ C[e i]  »  C[e2] _ 

(A (#z  =>  asJ.CJId]  »  (A(#z  =>  *).C)[e2] 
C[ei]  »  CM  e  >  e 
(C  =#  e)[ei]  »  (C  =#  e)[e2] 
e  »  e  C[ei]  »  C[e2] 


■w-D- 


(C  =  #C)[ex}  »  (e  =  #C)[e2] 
C[ei]  >  C[c2] 


/«,».[!]  JJ- 


/  H, 


>.[:]  4J- 


(isOVar  C)[e\]  »  (isOVar  C)[e2] 

□  [e.p.] 

Lemma  14  (Parallel  Reduction  Properties)  Vei  G  IE. 

1.  V6  Gl,e  GEi»e  =>  e  ~b 

2.  Ve  G  IE.  e  e. 
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ei [y.-  e2]  »  e3[y:=  eA}. 


3.  Vp.Ve i ,  e2  G  E.  ex  — >P  e2  =>  ei  >  e2 
•f  Ve2  €  E.  ex  — ►  e2  =>  ex  »  e2 

5.  Ve2  €  E.  ex  »  e2  =>  ex  — >*  e2 

6.  Ve3  G  E.  e2 ,  e4  G  E  ex  >  e3,  e2  »  e4  => 

Remark  15  Note  that,  from  1  it  follows  that 

1.  b  — >•  e  =>  e  =  b 

2.  \b  =  b 

3.  b  i — 7*  e  =>■  e  =  b 
Proof  (Lemma  If). 

Part  1  is  by  a  simple  induction  over  the  derivation  of  b  G  ®.  Part  2  is  by  a  simple  structural  induction  on  e.  Part 
3  is  by  a  case  analysis  over  p. 

1. 


,Al  '>  v  e[x:="]  "d  (A,Xe»l'c[*:I..]>'1>y  M'2(l 


2.  7T  i 


7Tx  [vi,v2)  — hr,  vi  and 


Vi  »  Vi 


TTl  (vi,v2)  »  nx 


4 


3.  ?r2 


7T2  (V!,v2)  — >•*,  v2  and 


v2  »  v2 


TTl  (vi,  v2)  >  W2 


4 


4.  02 


(\((£z  =>  x).e)  (ffz  =>  6)  - — J-/32  e[a;:  =  Aa;.6[#2::  =  a;]]  and 


e  »  e 


(A(#z  £).e)  (#z  =>  6)  >  e[*:  =  Aa;.&[#z:  =  a:]] 


>,by  14.211 


5.  03 


(Aie{fc}uL(y.  X,)  _+/,3  e*[**:  =  e]  and  ^,-g{fe}uL^, 


en  »  e„  u  >  n 


»)-c»)  (/fc  «)  >  en[^:=  w] 


»,by  14.2JJ- 


6-  # 


#2  =#  #2 — >#  True()  and  #2  =#  #2  »  True 


#z  ^  #z' 


and 


#2  7^  #2' 


#2  =  #z/  _»#  False()  #z  =#  #*'  »  False() 


7.  <5; 


isOVar 


isOVar  — >>  True()  and  — 


8.  IsOVar 


isOVar  »  True 


isOVar  t>  — ^  False()  where  i;  ^  #z,  and  7 


isOVar  i;  False() 


Proof  (Property  4  of  Lemma  14 )-  If  we  look  at  the  definition  of  — we  notice  that  if  e\  — >  en,  then  there  must 
exist  some  context  C,  so  that  e\  —  C[ef],  e 2  =  C[en],  and  e '  — >p  e" . 

Thus,  to  show  that  e\  — >  e<2  ==>  e\  e2,  it  is  enough  to  prove  that  for  any  context  C  €  C,  C[el]  C[e "]  => 
C[e' ]  C[en).  This,  however,  follows  directly  from  Lemma  13  (Compatibility  of  Parallel  Reduction), 
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Proof  (Property  5  of  Lemma  If).  Vei  G  E.Ve2  G  E.  t\  »  e2  ei  — >*  e2  By  induction  on  the  height  of  the 
derivation  e\  es. 


1-  0  >  ()and  ()  — >°  () 

2.  x^>  x  and  x  — >°  x. 

0  x  e  >  e'  ^ 

'  Xx.e  »  Xx.e' 


4.  »fr 


ei  »  e\ 
e2  »  e'2 

ei  e2  »  e'j  e2 


I H 


d  e2  — >*  ei  e'2 


comp.  — **  JJ 


comp.  — >•  JJ 


5-  »ft 


v  v' 
e  »  e' 


(A.r.e)  u  e'[a::  =  v']  (Aa;.e)  v  — (Aa:.e')  u  — >*  (Aaj.e')  v'  — e'[a::: 


comp. 


6. 


6»6' 

e  >  e' 


(A(#z  =>  a:).e)  (#2  6)  »  e'[r:  =  Aa:'.6'[#z:  =  a;']] 

r»JJ  ///JJ 
b  — ►*  6' 

„  _ L*  o' 


(A(#z  =>  a;).e)  (#z  =?>  6)  — >*  (A(#z  =>•  x).e')  (#z  =>  6')  — >^3  e'[x:  =  Aa,\6'[#z:  =  a;]] 


comp.  — JJ 


»fr 


7. 


ek  »  efc 
v  v1 

(XtervW  f  xj.ej)  ( k  v)  »  e'k[x\  =  v' 

7//JJ  7//JJ 

ek  — e'fc 


8.  »fj 

9.  »U 
10.  » fi¬ 
ll.  it> 

12.  fr » 

13. 

14.  >it 


(A /eF/  ary-ey  |A-  a^-.e*)  (A:  v)  — (A f€F  f  xj.es\k  xk.e'k)  (k  v')  — e'k[x:  =  v 

e\  >  ei  z=>  e\ 

e2  »  e2  ^  e2  — r  e 


— — -  comp.  _*  JJ 


e'i 


(ei,e2)  >  (ei, e'2) 
e  »e'  J2, 


(ej,e2)  — >*  (ei,e2) 


— — —  comp.  —  *  JJ 


7Ti 

e  7Ti  e' 

e  >  e' 

//f 

7T2 

e  >  7r2  e' 

Vl  » 

TTl 

(V1,W2)  » 

V2  >  t>2 

7T2 

<4 

7T  i  e 


7T  i  e 

I*  j 


comp _ JJ. 


7T2;e 

/H 


7T2;  e 


y  comp.  — ►*  JJ. 


e  »e'  ^ 


*1  (Kl,  «2)  - »/?,,  Vl 

«2  - 1*  V2 


—  comp.  — ►*  JJ. 


*2  (U1,W2)  - V2 


—  comp.  — JJ 


/  C  »  /  c'  fe—¥mfe 

ej  e'j 

XfeF(f  xf).ej  »  Al6F(/  x/).e'j 
15.  #z  >  #z  and,  #z  — >-0  #z 


—  comp.  — •  JJ 

;h 


e/ 


XiiF{f  xj).ej  — >•*  A^eF(/  xj).e)  ^  ^ ' 
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16.  »fr 

17.  »it 

18.  » Il¬ 
ls.  »it 
20 


f  »  e' 


#2  =>  e  »  #2  =>  e1 
e  »  e' 


#z  =>  e  — >■*  #2  =>•  e' 
m  « 


A(#z  =>  x).e  »  A(#2  =>  x).e'  A(#z  =>■  x).e  — >*  A(#2  =>  x).e 

d  »  ei  ==>  ei  - 


-  comp.  — ►  *  ^ 


e-2  »  4 


4 


«2 


ei  =#  e2  >  4  =#  4 


4  =#  e2 


#2  =  #2' 


#2  =  #2'  »  False() 
#2  =  #2; 


ei  =#  e2  - 
and  #2  =  #2'  — FalseQ 


—  comp.  — +•  1J. 


21.  »ir  t 

22. 

23. 


#2  =  #2'  >  True() 

e  »  e' 


and #2  =  #2'  — ►  #  True() 


e; 


- — ; 7“  COmp.  — ►  * 

isOVar  e  — >*  isOVar  e 


isOVar  e  isOVare' 

and  isOVar  #z  — ><5ii0Va,  True(). 


isOVar  #z  >  True() 
isOVar  v  False() 


and  isOVar  v  — ><5ij0Var  False() 


□ 


Proof  (Property  6  of  Lemma  1J().  The  property  is  stated  as  follows: 

Vei,e2,e3,e4  G  E.  ex  »  e3j  e2  >  e4  =>  e\ [y:=  c2]  >  e3[y:  =  e4] 

The  substitution  property  for  parallel  reduction  without  complexity  follows  directly  from  the  substitution  property 
for  parallel  reduction  with  complexity  (Lemma  18  on  page  14). 

Remark  16  From  Lemma  lJh  parts  4  and  5  above  we  can  see  that  that  '!$>*  = — >*. 

Proof  (Remark  16).  By  induction  on  the  derivations  of  — y*  and  ^>*,  and  has  two  parts. 

-  e\  — >*  e2  ==>  t\  ^>*  e2 


»*fr 


Cl  >  U 
u  >*  e2 
ci  >*  e2 


-  ei  »*  e2  =f>  ei  — >*  e2 

Assuming  that  t\  ^>*  e2,  it  must  be  the  case,  by  definition  of  that  there  exists  some  u\,  such  that  ei  ^  U\ 
and  u\  ^ > *  e2.  By  previous  property  14.5,  then  ei  — y*  u\.  But  for  that  to  be  true,  there  must  exist  some  u'  such 
that  ei  — y  uf  and  vf  — y*  u\ . 

To  show  that  ei  — y*  e2,  there  must  exist  some  u,  such  that  ei  — y  u  and  u  — >*  e2.  Let  uf  be  this  u.  Now,  we 
know  that  ei  — y  u  and  u  — y*  u\.  Since  u\  e2,  then  i/i  — **  e2  by  the  induction  hypothesis.  Since  u  — y*  u\ 
and  u\  — y*  e2,  by  transitivity  of  — y*  we  have  that  u  — y*  e2.  Therefore  u  — y*  e2  and  we  are  done.D 

Remark  IT  (Substitution  with  Complexity)  We  have  already  shown  that  parallel  reduction  without  complexity 
ts  equivalent  (in  many  steps )  to  normal  reduction  (in  many  steps).  The  same  result  applies  to  parallel  reduction  with 
complexity. 
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3.3  Substitution  Lemma  for  Parallel  Reduction  with  Complexity 

Lemma  18  (Substitution  for  Parallel  Reduction  with  Complexity)  Ve4,e5,e6,e7  EE,  X,Y  GN. 

e4  »  e5  A  e°  >  e7  =>  (3 Z  E  N.  e4[x :  =  e°]  >  e5[z:  =  e7]  A  Z  <  X  +  #(ar,  e5)Y). 

y  .  y 

Proa/  (Lemma  18).  Proof  is  by  induction  on  the  derivation  e4  >  e$.  Assumption:  e$  >  e7. 

1.  — -  and3Z  =  0.()[y:=c6]»()[y:=c7]AZ<0. 

0  »  0 


2. 


o 

^  >  a: 


(a)  If  x  —  y  then  3 Z  =  Y.x[y:  =  e^]  x[y:  =  e7]  A  Z  <  Y 

(b)  If  x  y  then  3 Z  =  0.x[y:  =  e^}  x[y\  =  e7]  A  Z  <  0 

N 

3.  - 1  ^  2 -  By  the  induction  hypothesis,  3Z\.e\[y\  —  e<s]  e2 [y:  =  e7]AZ  <  A  +  #(y,  e2 )Y  By  Barendregt’s 

Xx.ei  Aa:.e2 

1 

assumption  x  $  FV(ee,  e7),  so  3 Z  =  Z\  .Xx.ei[x:  =  x][y:  =  e$]  ^  Xx.e2[x:  =  x’][y:  =  e7]  A  Z  <  N  +  #(y,  Ax.e2)Y 
M  N 

A  61  63  2  —  .  By  the  induction  hypothesis,  we  obtain  the  following 


M+iV 

el  e2  e3  e4 


Z  i 


(a.)  3Zi.ei[y:=  e6]  »  e3[y:  =  e7]  A  Zi  <  A/  +  #(y,e3) 

(b)  3Z2.  e2[y:  =  e6]  >  e4[y:  -  e7]  A  Z2  <  A  +  #(y,e4) 

Then,  3Z  -  Zl  +  Z2.(e1  e2)[y:  =  c6]  >  (c3  c4)[y:  =  e7]  A  Z  <  (M  +  iV)  +  #(y,  e3  e4)Y 

M  N 

- — - 63 . . . — -  By  the  induction  hypothesis,  we  obtain: 

M+#(*,e3)N+l  J 

(Xxxxjvi  »  e3[z:  =  r2J 

(a)  3Zi  .ei  [y:  =  e6]  >  e3[y:  =  e7]  A  Z\  <  M  +  #(y,  e3)Y 

(b)  3Z2.vj[y:  =  e6]  >  =  c7]  A  Z2  <  N  +  #(y,  r2)Y 

Using  the  Barendregt’s  assumption  and  definition  of  substitution,  the  goal  can  be  stated  as  follows:  3 Z. 

2 

(Ax.ei[j/:=  e6])  (vi[y:=e6])  »  e2[x:  =  v2][y.  =  e7] 

By  property  of  substitution  (Lemma  12)  that  is  equivalent  to:  3 Z. 


2 

(\x.ei[y.  =  e6])  (v[j/:  =  e6])  »  e2[y.  =  e7][a::  =  v'[y.  =  e7]] 

By  Barendregt’s  assumption  x  is  not  free  in  any  therms  other  than  e\  and  e2,  and  inparticular  in  v9 .  From  this 
we  can  simplify  the  goal  further,  and  by  a  series  of  arithmetical  manipulations  obtain:  3Z  —  Z\  +  #(x,et)Z2  + 

L  ((Aar.ci)  v)[y:  =  e6]  »  e2[x:  =  v2][y:  =  e7]  A  Z  <M  +  #(x,  e2)N  +  1  +  #(y,c,[®:  =  t/])Y . 

M 

ci  »  e2 

(A(#2:  =>  a:).ei)  (#z  =>  6)  >  e2[^:  =  Aa?.6[#z:  =  a?]] 

By  the  induction  hypothess:  3^i.ei[y:  =  ee]  e2[y:  =  e7]  A  <  M  +  #(y,  e2)Y.  The  goal  is:  3 Z. 


(((A#z  =>  x).e\)  (#z  =>  6))  >  e2[x:  =  A®;.6[#z:  =  x']\[y:  =  e7]  A  Z  <  M  +  1  +  #(y,  c2[a?:  =  Aa?'.6[#z:  =  ar7]]) 
Since  FU(6)  =  0,  this  can  be  simplified  to 

(((A#z  =>  x*).ei)  (#z  6))  >  e2[x:  =  Aa?7.6[#ar:  =  x7]][y:  =  e7]  A  Z  <  M  -f  1  -f  #(y,  e2) 

Then  further,  by  “permutation”  of  subsitution: 

(((A  #z  =>  x).e\)  (#z  =>  6))  >  e2[y:  =  e7][x:  =  A«7.6[#2r:  =  a:7]]  A2<M+1  +  #(y,  e2) 

Now  the  goal  follows  easily  when  Z  —  Z i  T  1. 
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M  N 

e/c  »  e'k  vi  »  v2 


(A/efu{fc}y  a;/.e/)  (/A.  vj)  »  e'fe[a.-fc:: 


By  the  induction  hypothesis  we  have 


(a)  3Zi.ek[y:=  e6]  >  4 [y:  =  e7]  A  Zi  <  M  +  #(y,e'k)Y 

(b)  3Z2.vi[y:=  e6]^  v2[y:=  e7]  A  Zi  <  N  +  #{y,v2)Y 

Using  Barendregt’s  assumption  and  the  definition  of  substitution,  the  goal  can  be  restated  as  follows:  3 Z. 

((A«eFu{A ■}  f  X}.ej)  (fk  Wl))[y:=  e6]  »  e'k[x\  =  v2][y:  =  e7]  A  Z  <  (M  +  #(x,e'k)N  +  1)  +  #(y,  e'k[x:  =  v2])Y 
By  property  of  subsitution  (Lemma  12),  we  obtain  3 Z. 


((^16FU{A-}/  Xf.ej)  (fk  vj  ))[«/:=  e6]  »  4b:=  e7][z:  =  v2[y:=  e7]]  A  Z  <  (M  +  #(x,e'k)N  +  1)  +  #(y,e'k[x:  -  v2])Y 

By  the  induction  hypothesis,  properties  of  substitution  and  arithmetic  the  above  goal  follows  when  Z  =  Z\  + 

#(*^2  +  1. 

M  N 

— — - - — -  By  the  induction  hypothesis,  we  obtain 

(ei,e2)  »  (e2,e4) 

(a)  3Zi .  ei[y:  =  e6]  »  e3[y:  =  e7]  A  Z\  <  M  +  #(y,  e3)Y 

(b)  3Z2.e2[y:  =  e6]  »  eA(y.  =  e7]  A  Z2  <  N  +  #(y,  e4)Y 

Then,  it  follows  3Z  =  Z\  +  Z2.  (e x ,  e2)[y:  —  e7]  »  (e3  e4)[i/:  =  e7]  A  Z  <  (M  +  N)  +  #(j/,  (e3,  e4))Y 
By  the  induction  hypothesis  we  obtain 


M 

t\  >  e2 


10. 


11. 


M 

71*1  Cl  >  7Ti  e2 

=  c6]  >  e2[y:  =  67]  A  <  M  +  #(y,  e2)y.  Then,  3Z  =  Zifwi  e\)[y:  =  e6]  >  (7Ti  e2)[y:  =  e7]  A  Z  < 

M  +  #(y,e2)y. 

M 

Ci  ]!$>  C2 

For  the  derivation  - — — 1 -  By  the  induction  hypothesis  we  obtain 

7T2  ei  >  7t2  e2 

3Z1.e1[y:  =  e6]  >  e2[y:=  e7]  A  Zi  <  M  +  #(y)e2)Y.  Then,  3Z  =  Zi.(tt2  d)[y:  =  e6]  J>  (tt2  e2)[y:~  c7]  A  Z  < 

M  +  #(t/,e2)y. 

N  / 
vj  > 


71"  1  (t>l,  V2)  >  *>l 


12. 


By  the  induction  hypothesis  we  obtain:  3Zi.  t>i[y:  =  e6]  >  ^  [y:  =  e7]  A  Z\  <  N  -F  #(y,  t/^y . 

Then  3Z  =  Zi  -f  1.  (i>i,  v2))[y:  =  e6]  >  vi[y:  =  e7]  A  Z  <  N  +  1  +  #(y/  i>i)y. 

N  , 
l>2  >  ^2 


7T2  (t^I  ,  V2  )  >  V2 


Zi 


13. 


14. 


By  the  induction  hypothesis  we  obtain:  3Z\.v2[y:  —  e6]  >  =  e7\  A  Z\  <  N  +  #(y,  ^2)T . 

Then  3Z  =  Z\  +  1.  (tti  (wi,  w2))[y:  =  e6]  >  v‘2[y:  - e7]AZ  <N  +  l  +  #{y,'  v2)Y. 

M 

Z\  »  e2 

M  ‘ 

ft  1  >  /  e2 

By  the  induction  hypothesis  3Z\.e\[y:  —  eg]  %>  e2[y-  =  e7]  A  <  M  +  #(y,  e2)Y. 

Then  3Z  =  ^.(Z  ex)[y.  =  c«]  >  (/  e2)[j /:  =  c7]  A  Z  <  M  +  #(j/,  /  e2)Y. 

e/  >  e'j 

N 


X^F  f  Xf.ej  »  A feFf  Xf.e'j 
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By  the  induction  hypothesis  V/  E  F. 


3 Zf.ej[y:=  e6]  »  e^[y:  =  e7]  A  Z}  <  Nj  +  #{y,e'f)Y 

Then  3Z  =  Yl/qF  Zj.(\^F  f  xj.ej[y:=  eg])  >  e'f[y-=  £7]  A  Z  <  +  S#(2/.e/)Y- 

15.  - 5 -  and3Z  =  0.#z[y:  =  ee]»#*[y:=er]AZ<0  +  0-y 

#2  >  #z 

M 

&  1  (3  o  1 

16.  - — — 1 2 -  By  the  induction  hypothesis,  3Z\.  e\[y.  —  e^}  ^  e2 [y:  =  e7]  A  M  +  #(t/,  e2)Y .  Then, 

(#z  =>  ei)  >  (#^  =>  e2) 

3Z  =  Zx.{#z  =>  e  1 ) [2/:  =  eg]  »  (#2  =>  e2)[j/:  =  e7]  A  Z  <M  +  #{y,#z  =>  e2). 

N 

17.  - 61  2 -  By  the  induction  hypothesis,  we  obtain  3Z\.  ei[y:  =  eg]  e2 [j/:  =  e7]  A  Zi  < 

A(#z  =>  ®)-ei  >  A(#z  =>  a,').e2 

N  +  #(y,e2). 

Then  3 Z  =  Zx.(#z  =>  ej )[y:  =  e6]  >  (#z  =>  e2)[y:  =  e7]  A  Z  <  N  +  #(y,  #z  =>  e2)Y 

18.  - - -  ,  3 Z  =  l.(#z  =#  z)[y:  -  e6]  »  True()[j/:=  e7]  A  Z  <  1  +  #(y,True()) 

#z  =#  #z  »  True() 

19.  - ----- -  ,  3Y  =  l.(#z  =#  z')[y:  =  e6]  >  False()[y:  =  e7]  A  Z  <  1  +  #(y,  False()) 

#z  =#  #z'  »  Faise() 

M  N 

on  ei  e3  e4 

M  +  iV 

ei  =#  ^2  >  e3  — #  e4 

By  the  induction  hypothesis  we  obtain 

%  l 

(a)  3Zi.ei[y:  =  e6]  >  e3[y:=  c7]  A  Zi  <  M  +  #(2/,  e3)Y 

(b)  3Z2.e2[xj\  -  e6]  §>  e4[y:  -  e7]  A  Z2  <  N  #(y,  e4)Y. 

Then  3Z  =  Zi  +  ^2-  (ei  =#  e2) [y:  =  e6]  »  (e3  =#  e4)[y:  =  e7]  A  Z  <  (M  +  N)  +  #(y,  (ee  =#  e4))Y. 

A  , 

21.  - -  By  ^ie  induction  hypothesis,  3Z\.e[y\~  eg]  ^  e'[y::=  ee]  A  ^  <  X  -f  #(y,e')Y.  Then, 

isOVar  e  isOVar  e' 

3Z  =  Z\.  (isOVar  e)[y:  =  eg]  (isOVar  e')[y:  =  e7]  A  Z  <  X  +  #(y,  isOVar  e'). 

22.  - - -  and  3Z  =  1.  (isOVar  #z)[y:  =  eg]  True()[y:  =  e7]  A  Z  <  1  +  #(y,  True())Y . 

isOVar  True() 

23.  * . . --p- -  Then,  3Z  =  1.  (isOVar  v)[y:  =  e6]  >  False()[y:  =  67]  A  Z  <  1  +  #(y,  False())Y. 

isOVar  i;  False() 


3.4  Big-Step  Semantics 

Lemma  19  (Basic  Property  of  Big-Step  Semantics)  If  e  ef  then  e'  £  V. 
Proof  Proof  is  straightforward  by  induction  over  the  height  of  the  derivation.  □  [e.p.] 


3.5  Classes 

Lemma  20  (Basic  Properties  of  Classes) 


1.  V,  W,  §  C  E 

2.  V,  W,  §  partition  E. 
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Proof.  Proof  is  by  structural  induction  on  e,  and  then  by  pattern  matching  on  e.  The  following  table  summarizes 
this  rather  tedious  proof: 


e  G  E 

G  V 

GW 

G  § 

0 

Yes 

No 

No 

X 

No 

No 

Yes 

Xx.e 

Yes 

No 

No 

(Xx.e)  v 

No 

Yes 

No 

(A (#z  =►  ®).e)  (#*  =>  b) 

No 

Yes 

No 

(A -ftr f  xj.ef)  (/  v) 

No 

Yes 

No 

iv  e 

No 

Yes 

No 

v  w 

No 

Yes 

No 

(¥\Ae)  v 

No 

No 

Yes 

s  i  e 

No 

No 

Yes 

?;  s 

No 

No 

Yes 

(A (#^*).e)  (¥\#*=>6) 

No 

No 

Yes 

f  xj.ej)  (V\(/  v)) 

No 

No 

Yes 

Exhaustive/Nonoverlapping:  Yes 

(^1 ,  v2) 

Yes 

No 

No 

(iy,  e) 

No 

Yes 

No 

No 

Yes 

No 

(»>  e) 

No 

No 

Yes 

(w,s) 

No 

No 

Yes 

Exhaustive/Nonoverlapping:  Yes 

TTl  ( Vl ,  V2  ) 

No 

Yes 

No 

7Ti  iy 

No 

Yes 

No 

TTl  (V\  (t>i,  V2)) 

No 

No 

Yes 

7T  i  S 

No 

No 

Yes 

Exhaustive/Nonoverlapping:  Yes 

1 

e  G  E 

G  ¥ 

G  W 

E  § 

7T2  {vUV2) 

No 

Yes 

No 

7T2  W 

No 

Yes 

No 

n 2  (V\  (vi,w2)) 

No 

No 

Yes 

7 r2  s 

No 

No 

Yes 

Exhaustive/Nonoverlapping:  Yes 

fv 

Yes 

No 

No 

f  w 

No 

Yes 

No 

f  s 

No 

No 

Yes 

Exhaustive/Nonoverlapping:  Yes 

A fel“(f  xf).ej 

Yes 

No 

No 

Yes 

No 

No 

#z=>v 

Yes 

No 

No 

#z  =>  w 

No 

Yes 

No 

s 

No 

No 

Yes 

Exhaustive/Nonoverlapping:  Yes 

X {if1?  x).e 

Yes 

No 

No 

=#= 

II 

=H= 

No 

Yes 

No 

w  =#  e 

No 

Yes 

No 

#z  =#  w 

No 

Yes 

No 

(V\#z)  =#e 

No 

No 

Yes 

#z=#  (V\#z) 

No 

No 

Yes 

s=#  e 

No 

No 

Yes 

)jzz  —  #  S 

No 

No 

Yes 

Exhaustive/Nonoverlapping:  Yes 

isOVar  v 

No 

Yes 

No 

isOVar  w 

No 

Yes 

No 

isOVar  s 

No 

No 

Yes 

Exhaustive/Nonoverlapping:  Yes 

□[e.p.] 


3.6  Parallel  Reduction  and  Classes 

There  is  a  sense  in  which  parallel  reduction  should  respect  the  classes.  The  following  lemma  explicates  these  properties. 

Lemma  21  (Parallel  Reduction  and  Classes) 

M 

1.  Ve  €  E,  v  E  V.  v  »  e  =>  e  E  V 

M 

2.  VeGE ,sE§.s»e=>eeS 

M 

3.  Ve  E  E,  w  E  W.  e  w  =>  e  E  W. 

Proof  (Lemma  21.1).  By  structural  induction  on  v  E  V. 

1.  ()  EVand  ()»()EV 
e  e/ 

2  -  and  Xx.ef  E  V. 

Ax.e  Xx.e 
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3.  »1\ 


vi  >  ei 

V2  >  e2 


^  ci  G  V 
62  €  V 


(^1 , v2)  »  (ei,e2)  (ei,e2)GV 


€vjj- 


4<  ^  r  TTTTt 

f  v^>  f  e  /  ^  EV 

5.  XieL  fi  Xi.ei  »  XieL  fi  Xi.t\  and  XteL  /,•  £*.e-  G  V 

6.  #zE  V  and  #2:  ;$>  #2  G  V 

v^>vf  ^  v'  e  v 

^  #2  =>  V  #2:  ?/  #2  =>  vf  G  V 

8.  A(#z  =>  .T).e'  G  V  and  A(#2  =>  z).e  >  A(#2  =J>  z).e'  G  V 


Proof  (Lemma  21.2). 


By  structural  induction  on  s  G  §. 

1.  xG§  and  x  ^  .x  and  x  G  § . 

ei  >  e2  =>  e2  G  IE 

«i  >  e3  ^  e3  G  § 


M 


Ve  G  E,  s  G  5.  s  e  =>  e  G  S 


2. 


si  ei  >  e3  e2 
v  >  ei 


£3  e2  E  S 
ei  E  V 


s  >  e2  JJL  e2  G  § 

3.  »ft  - - -  - TTT  e4 


V  s  >  ei  e2 


ei  e2  G  § 


4-  »n- 


5-  »fr 


6. 


(A (#2  =>  x).e)  »  (A(#z  =>  a;).e') 
v  v1  v£V\ (#z  =J>  6) 

(A(#z  =>  *).e)  u  (A (#z  =>■  ®).e)  v' 

v  v' 


s  >  s' 

TH 

s'  e  § 

e4 

K«)  »  (v',s') 

(t/y)  g  s 

e  >  e' 

>x 

e'  €  E 

Sl  >  si 

I H 

Si  G  S 
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(s!,e)  »  (s'j ,  e') 

(si,  e')  G  S 

t»,€V\(#g=>6) 
(A (#7  =l>  a:).e)  v1  S  § 


s-IJ. 


7- 

8.  »fl 
9-  »ft 

10.  »ft 


«  »  s'  ^  s'  G  § 


e4 


7T„  S  S'  7r”  s'  G  § 

v  ^  v'  v  E  (V  \  (w,  w))  v'  G  (V  \  (v,  u)) 

7Tn  V  »  7Tn.  l/ 

s  »  s'  ^  s'  €  S 


7fn  v'  €  § 
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/  fi  »  /  S'  /  s'  €  §  '<4 

\f€F  f  xj.ej  »  A7eF/  xj.e'j 
v  »  t/  v  G  (V  \  /  v) 


(XJ£F  f  xj.ej)  v  »  {\f£F  f  xj.e'j)  v‘ 

,,  A  *»«'  ^  «'e§ 

11-  »fl  — — : — r-^ — : — r  ~ — —rzrz 


«'  G  (V  \  /  i;) 

(A/€f  J  a,-y  ,ey)  t)'e§ 


12. 


#Z  =>  S  »  #Z  s' 

x  t?'  v  G  (V  \  IB) 

#2  =>  v  >  #2  =>  t/ 


#2  =>  s;  G  § 
x7  G 


#z^v'  e§ 


6sJ| 
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e  »e' 

A  v>v'  Ve(v\#z)  ^  v'  e  (v\#z)  „ 

13'  ^  t;  =  e  » v'  =  e'  t/  =  e'€S  ^ 

#z  >  #z 

^  A  u»i/  ^G(V\#z)  6  (V \  #z)  .. 


14.  »ft 


15.  »fl 


16.  »ft 


17.  »ft 


#r  =  i;  >#2  =  1;' 

e  e7  =>  e7  E  E 

s  »  s7  TEi  5'  E  § 


s  =  e  >  5i  “  52 


s7  =  e7  E  S 


5>5;  ^  S7  E§ 

#2  =#  5  >  #Z  =#  S7  #Z  =#  5'  E  § 

v2  »  e2  ^2  €  v  >^1  e2  E  V 
^i>e!  ^iE(¥\Ae)  eiE(V\Ae) 

i>i  t>2  >  ei  ^2  ei  e2  E  S 


18.  »ft  T 


sOVar  5  isOVar  e 


isOVar  e  E  § 


Proof  (Lemma  21.3). 

Ve  E  E,  E  W.  e  ]^>  w  =>  e  £  W. 
Property  3  follows  directly  from  the  previous  two  properties.  □ 

3.7  Left  Reduction 

Lemma  22  (Left  Reduction  and  Classes) 


1.  Vw£W.(3e'£E.w-^e/) 

2.  Ve  E  E.  (3e7  E  E.  e  ■ — ¥  el)  =>  e  £  W 

3.  VuE  V.-i(3e'EEv  >  e7) 
i  Vs  E  51.  -i(3e/  E  E.  5  i — >  e7). 

Proof  ( Lemma  22).  We  only  need  to  prove  the  first  two,  and  the  second  two  follow.  The  first  one  is  by  straightforward 
induction  on  the  judgement  e  £  W.  The  second  is  also  by  straightforward  induction  on  the  derivation  e  i — ¥  e* . 


\fw  £  W.  {Be'  £  E.  w  «— >  el) 


By  structural  induction  on  w. 


1.  (Aa;.e)  v  « — ¥  e[x:  =  v]and  e[x:  =  v]  £E 

2.  (A(#_  =>  x).e)  (#2  =>  6)  i — I  e[a?:  =  A.x7.6[#2:  =  a?']]  and  e[.x:  =  \x'.b[j)z:  =  a?7]]  E  E 

u;  i — >  it/ 

3  ( — t  jj-  - - — 

w  e  < — ¥  w  e 

w  i — ¥  w'  fJL  w'  £  E 

4  -  -  €E^ 

x  u>  i — >  x  u/  vw  E  JE 

w  i — »  u/  V  EE 

5.  i — f-ff  -  —  —  €EV 

/  w  i — ¥  f  w  f  w  £  E 

w  i — ¥  wf  ffL  wf  £  E 

6-  T  7”  I  77  "  .../  “#77  I  777  7  77  €E^ 


/  w  i — >  /  w' 

w  i — ¥  wf 


f  w*  £  E 

JJk  w'  £  E 


#2  =>  u;  i — )■  #z  =>  u/ 


#2^Vee 
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7. 

8. 

9. 

10. 


►  ft 
►ft 
►ft 

►  ft 


(w,e)  1 — 

>•  (tw',  e) 

W  1 - 

>  in' 

K«o  1 — 

>  (n,  in') 

W  1 - 

■>  in' 

IH 

in  —  e  1 — 

*  in'  =  e 

in  h 

— ^  in7 

w'eE 
(u/,e)  G  E 
to'eE 
(w,ty')  G  E 
uj'eE 


€1E-IJ- 


eitlj. 


tt) 

IH 


e  E  E 
u/  e  e 


eEjj. 


=  w  i — >  #z  =  w'  #z  =  wf  E  E 

11.  =  #z'  i — >  TrueQand  True  E  E 


€EJ)- 


12. 


►ft 


u/  E  E 


7Tn  uj 

13.  v2)  •- 

14.  7T2(^l  ,  v2)  »- 

15.  isOVar 

16.  isOVar  t;  k- 

17. 


7Tn  ll/  7Tn  It/  G  E 


6E-1J- 


and  v\  G  E 
v2  and  v2  E  E 
True()  and  TrueQ  G  E 
False()  where  v  ^  and  False()  G  E. 


in  1 


in 


w'ge 


€El| 


isOVar  in  • — y  isOVar  in '  isOVar  in'  E  E 

Part  2  is  proven  by  induction  on  the  height  of  derivations  of  e 


e',  and  by  case  analysis  on  e 


Ve  G  E.(3e'  GEeMe'J^eGW 


1. 


2. 

3-  ^ft 

4. 

5.  ^fr 

6. 

7- 
8. 


(Aane)  v  1 — >  e[x:  =  n] 
ci 


e'i 


and  (Ax.e)  n  E  W 

eiGF 


6*i  e2  1 — y  e2 


v  e  1 — ►  v  e 


ei  e2  E 


ewJJ- 


e  G 


ei 


n  e  G  W 
z^>  eiG’ 


(ei,e2) 

1 — y  (ci ,  e2) 

e  i- 

— >e'  SZ, 

(t),e)  1 

->(v,e')  1 

e  1 — 

>  e'  e 

7Ti  e  • — 

->  TTie'  7T 1 

e  1 — 

>  e'  e 

(ei,e2)  G  W 
f=  W 

€wfl 


(1/,  e)  G  W 
GW  JL 

-  ewU 

_  TT-nr  v 


€wjj- 


7t2  e  1 — ►  7r2e'  7t2  e  G  W 

and  7r  1  (in ,  n2)  G  W 


TTl  (Ul,  V2)  1 - >  Vi 

9.  - 7 - - -  and  7 r2  (in ,  n2)  G  W 

7T2  (^i,  V2)  1 - >  V2 


10. 


(A /€Fu{/c}  j;/).e/)  (fc  i>)  t — >et[**:=  v] 

e  1 — y  e'  ^  e  G  W 

11.  -ft 


,  and  (VeFu^ft  (/  Xf).e/)  (k  v)  G  W 


/  e  >— ►  /  e' 


12.  ~ft 


/e  G  W 

^  e  G  W 


#z  =>  e  1 — ►  #z  =>  e' 


=>  e  G  W 


€w|l 


13. 


(A(#z  =>  x).e)  (#z'  =>  6)  1 — »  e[z:  =  Aa/.6[#z':  =  a/]] 


and  (A(#*  =>  a?).e)  (#z'  =*  6)  G  W 


14. 


ci 


ei  G  W 


ci  =#  e2  i — y  e[  -#  e2 


ei  =#  e2  G  W 


;WJ| 
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15. 


e  6 


#2'  =#e — >•  #2'  =#  e' 


=#  e  e  W 


€wj| 


16. 

17. 


#z  =#  2  h-j.  True() 
#*  ±  #*' 

#z  =#  2'  1 — >■  FalseQ 


and  $z  =#  E  W 
and  #2  — #  #z  E  W 


18. 

19. 

20. 


isOVar  #z  1 — ►  True() 

v±#z 


isOVar  v 


False() 


and  isOVar  E  W. 
and  isOVar  z;  E  W. 


e  E  W 


isOVar  e  1 — ^  isOVar  e' 


isOVar  e  E 


€wj| 


□  [e.p] 

Remark  23  (Left  Reduction  Determinism)  From,  the  above  it  easily  follows  that  for  any  expression  e  E  E,  if 
e  1 — ►  e'?  then  there  is  only  one  derivation  by  which  e  1 — *  e'.D 


4  General  Part  of  Confluence 

The  Church- Rosser  theorem  [1]  for  — >  follows  from  Takahashi’s  property  [9]  (Theorem  27).  The  statement  of 
Takahashi’s  property  uses  the  notion  of  a  complete  development . 


4.1  Parallel  Reduction  is  Diamond 

Lemma  24  (Parallel  Reduction  is  Diamond)  Ve i,e,e2  E  E. 

ci  <  e  »  e2  =>  (Be'  E  E  ei  »  e'  «  e2). 


4.2  Takahashi’s  Property 

Proof  Take  e'  =!e  and  use  Takahashi’s  property  (Theorem  27).  □ 

4.3  Main  Confluence  Result 
Theorem  25  (Main  Confluence  Result)  . 

Vei ,6,62  GE.  ei  < — *  e  ~ — e2  =>  Be'  E  E.  e\  — e'  < — *  e2 
Proof  (Theorem  25).  Follows  directly  from  Lemma  24.  □ 

5  Special  Part  of  Confluence 

Remark  26  By  a  simple  induction  on  e,  we  can  see  that  e  ^>\e. 

5.1  Takahashi’s  Property 

Theorem  27  (Takahashi’s  Property)  Vei,e2  E  E. 

ei  >  e2  ==>  e2  'S>\e1. 
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Proof  (Takahashi’s  property  for  ). 


Ve i ,e2  EEei  >  e2  =>>  e2  >!e2 
By  induction  on  the  height  of  the  derivation  e\  ^  e2. 


1.  ()  »  ()  and  ()  »!(). 

2.  For  x  x  and  x  ^>!x 


3- 


e  e'  -221.  e'  ^>!e 


4. 


5. 


Ax.e  »  Ax.e'  (Ax.e')  »!(Ax.e) 

»>»'  ==>  ?/ 

e  >  e'  ^  e'  »!e 


(Ax.e)  v  e'[x :  —  v ']  e'[x\  =  n']  ^>!((Aa:.e)v) 


14.6,!.: 


_ e  >  e' _ 

(A (#z  =>  x).e)  (#2  =>  6)  »  e'[x:  =  \x'.b[#z:  =  x']] 


e'  »!e 


e'[x:  =  A x'.b[#z:  =  x']]  »  !((A(#2  =>  x).e)  (#2  =>  6)) 


6. 


v  ~^>  v' 
Ck  >  e'k 


IH 

=> 

IH 


v' 

e'k  »!efc 


(A feFvW  f  XJX})  (*.  v)  >  e>k[x.  =  „/]  e^x:  =  t/]  »!((A^Fu^>  /  xy.e,)  (Ar  «)) 


!,>,14.6jJ- 


7.  »fr 


8.  »it 


9. 


e2  »  e'2 

ei  »  e'j  _ 

d  e2  »  e'j  e'2  {e\  e'2)  »!(ei  e2)' 


IH 


e2  »!ei 

e;  >!ei 


>,4 


e2  >  e'2 
ei  »  e'j 


/  H 
=> 
IH 


e2  »!e2 

ei  »!ei 


(ei,e2)  »  (ei,e'2)  (e'x , e'2)  »!(ei,e2) 

e  e'  e'  ^>!e 


d  e  >  e'  (ffie')  ^>!(7ne) 
e  »  e'  ;22i  e'  »!e 

10.  - -  - - — - — - “  »,4 

7r2  e  >  7t2  e'  (7r2e')  »!(7r2e) 

. .  .  t>i  » w'j  i>i  »!«i 

ii-  »ir 


fl  4l,  «2)  »  «'l 

V2  >  = 

7T2  (t>l  ,  t)2)  »  V2 

e  »  e'  =££.  _ 

/  e  »  /  e'  /  e'  >!(/  e 

_ e/  >  ej _ 


v[  »!(tti  (vi,v2))' 
v'2  »b2 

v2  »!(7T2  ( Vl,V2))' 

e'  »!e 

.4 


12.  »i\ 

13. 

X^€F  f  x f  ,ej  f  xj .e'j 

15-  #2  #z  and  #2  »!#z 

e  » e'  J22L  e'  »!e 

16.  »fl-  ^ 


>.4 

>.4 


.4 


£/  >!e/ 


17.  »D 

18.  »1> 


#z  =>  e  >  #2  =>•  e' 
e  »  e' 


#2  =>  e'  >!(#2  =>  e) 


A7€F  /  x/.ey.  »!(A7€f  /  xj.ej) 

.4 


4 


e'  »!e 


A(#z  x).e  A(#2  x).e'  A(#z  =>  x).e'  >!(A(#z  =>  x).e) 

ei  »  ei  e2  »  e'2  ^  ei  »!ex  e'2  »!e2 
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ei  =  e2  »  ei  =  e'2  (ei  =  e'2)  >!(ei  =  e2)' 

19.  #z  =  #2  »  TrueQ  and  True()  »!(#2  =  #2) 

20.  #2  ^  #2'  #2  =#  2#z'  »  False()  and  False()  >!(#z  =#  #2') 


21.  isOVar  True  and  True()  ^>!(isOVar  #z). 

22.  - V  ^  - —  ,  and  False()  ^>!(isOVar  v). 

isOVar  v  False() 

e  >e'  ^  e'>ie 

^  isOVar  e  >  isOVar  e'  isOVar  e*  >!(isOVar  e) 

□[e.p.] 

6  General  Part  of  Computational  Adequacy  of  Reduction  Semantics 

6.1  Main  Soundness  Theorem 
Definition  28  (Observational  Equivalence) 

ex  «  e2  =  VC  G  C.  C[ex]  ^  C[e2]  U 


Definition  29  (Termination) 


ei  JJ-=  3v  G  V.ei  ^  ^ 


Theorem  30  (Soundness  Theorem) 

Vei ,  e2  E  E.  ei  — >  e2  =>  ex  «  e2 
Proo/  (Theorem  30).  By  the  definition  of  to  prove  our  goal 

Vex ,  e2  G  E.  ex  — *  e2  =>  e1  «  e2 


is  to  prove 

C  E  C.  Vex ,  e2  E  E  ex  — e2  A  C[ei],  Cf[e2]  E  IE  =>  (C[ex]  JJ.  C[e2]  fj- 

Noting  that  by  the  compatibility  of  — we  know  that  C  E  C.  Vex,e2  E  E.  ex  — >  e2  => 

sufficient  to  prove  a  stronger  statement: 

C  E  C.  Vex ,  e2  E  E.  C[e  1]  — ►  C[e2]  A  C[ex],  C[e2)  G  E  ==>  (C[ci]  U  <=>  C[e2]  ^  ). 

Noting  further  that  C  G  C.  Va,  6  G  E  a  =  C[b\  G  E  a  G  E,  it  is  sufficient  to  prove  an  even  stronger  statement: 

Vex,  e2  G  E  ex  — »  e2  =>  (ex  Ij.  <!=>  e2  Jj. ). 

This  goal  can  be  broken  down  into  two  parts: 
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Vex,  e2  G  E.  ex  — »  e2  =>  (ex  =>  e2 JJ. ), 

and 
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Vex ,  e2  G  E  ex  — *  e2  =>  (e2J|  =>  exJJ. ). 

Let  us  consider  SI.  By  definition  of  termination,  it  says: 

Vex ,  e2  E  E  ex  — >  e2  =^>  ((3r  G  V.ej  H  v)  =>  (3u  E  V.  e2  i;)). 

We  will  show  that  big-step  evaluation  is  included  in  reduction  (Lemma  34).  Thus,  to  prove  S2  it  is  enough  to  prove: 
Vex ,  e2  G  Ecx  — >  e2  =>  ((3v  G  V.ej  * — >*  v)  =>  (3v  GV.e24  v)). 


)• 

C[ei]  — *■  C[e2],  it  is 
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Confluence  (Theorem  25)  tell  us  that  any  two  reduction  paths  are  joinable,  so  we  can  weaken  our  goal  as  follows: 

Vei ,  e2  E  E.  e\  — >  eg  =>  ((3c  E  V,e3  G  E.  ej  — »*  c  — >*  e3  A  e 2  — >*  63)  =>  (3c  E  V,e2^r)) 

We  will  show  (Lemmas  21  and  Remark  16)  that  any  reduction  that  starts  from  a  value  can  only  lead  to  a  value  (at 
the  same  level).  Thus  we  can  weaken  further: 

Vei ,  e2  E  E.  e\  — »  e2  =>  ((3c,  c3  G  V.  — >*  v  — ¥*  c3  A  e2  — >*  c3)  ==>  (3c  GV.e24  v)) 

In  other  words,  we  already  know  that  e2  reduces  to  a  value,  and  the  question  is  really  whether  it  evaluates  to  a  value. 
Formally: 

Vei ,  e2  G  E.  e\  — »  e2  =>  ((3c3  G  V.  e2  — C3)  =>  (Bv  E  V.  e2  <-4  c)). 

In  fact,  the  original  assumption  is  no  longer  necessary,  and  we  will  prove: 

T1 


Ve2  E  E.  ((3^3  E  V.  e2  — c3)  =>  (Bv  E  V.  e2  -4  c)). 

Now  consider  S2.  By  definition  of  termination,  it  says: 

Vei ,  e2  E  E.  ei  — *  e2  =>  ((3c  EV.e24t;)  =>  (Bv  EV.e^ti)). 
again,  by  the  inclusion  of  evaluation  in  reduction,  we  can  weaken: 

Vei,e2  E  E.  ei  — *  e2  =>  ((3c  E  V.e2  — >*  v)  =>  (3c  E  V.ei  ^  c)). 
Given  the  first,  assumption  in  this  statement  we  can  also  say: 

Vei,e2  E  E. €1  — >  e2  ==>  ((3c  E  V.ei  — c)  =>  (3c  E  V.ei  4  c)), 
and  we  no  longer  need  the  assumption  as  it  is  sufficient  to  show: 

T2 


Vei  E  E.  ((3c  E  V.  ei  — >*  c)  =>  (3c  E  V.ei  4  V)). 
But  note  that  T1  and  T2  are  identical  goals.  They  state: 


T 


Ve  E  E.  ((3c  E  V.  e  — >*  c)  =4  (3c  E  V.  e  4  c)). 
This  statement  is  a  direct  consequence  of  Lemma  31. 

It  is  easy  to  show  that  e  4  v  =>  e  — >*  c,  as  it  follows  directly  from  Lemma  34. 


□ 


6.2  Reduction  is  in  Evaluation 

Lemma  31  (Reduction  is  in  Evaluation)  Ve  E  E,  Ci  E  V. 

e  — »*  ci  =>  (3c3  E  V.e4C3  — >*  Ci). 

Proof,  We  arrive  at  this  result  by  an  adaptation  of  Plotkin’s  proof  for  a  similar  result  for  the  CBV  and  CBN  lambda 
calculi  [3].  The  main  steps  in  the  development  are: 

1.  We  strengthen  our  goal  to  become: 

e  — ci  =>  (3c3  E  V.e4  V3  — ¥*  ci). 
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2.  We  define  a  left  reduction  function 


(Section  2.11)  such  that  (Lemma  36):  Ve  G  E,  v  G  V. 


e  i — e  <— >•  v 

and  Vei,  e2  G  E.  e\  ^ — *  e2  =>  ei  — >  e2  (Lemma  35).  Thus,  big-step  evaluation  (or  simply  evaluation)  is  exactly 
a  chain  of  left  reductions  that  ends  in  a  value. 

3.  Our  goal  is  restated  as: 

e  — >*  v\  =>  (3^3  G  V.  e  \ — »*  V3  — >*  ^i). 

4.  For  technical  reasons,  the  proofs  are  simpler  if  we  use  a  parallel  reduction  relation  (Section  2.8)  similar  to  the 
one  introduced  in  the  last  section.  Our  goal  is  once  again  restated  as: 

e  v\  =>  (3t>3  G  V.  e  \ — V3  ^ > *  ^i). 

5.  The  left  reduction  function  induces  a  very  fine  classification  (V,W,  §)  on  terms.  In  particular,  any  term  e  G  E 
must  be  exactly  one  of  the  following  three  (Lemma  20): 

(a)  a  value  e  G  V, 

(b)  a  workable  e  G  W,  or 

(c)  a  stuck  e  G  §, 

where  membership  in  each  of  these  three  sets  is  defined  inductively  over  the  structure  of  the  term.  We  write  v,w 
and  s  to  refer  to  a  member  of  one  of  the  three  sets  above,  respectively.  Left  reduction  at  level  n  is  a  total  function 
exactly  on  the  members  of  the  set  Wn  (Lemma  22).  Thus,  left  reduction  is  strictly  undefined  on  non-workables, 
that  is,  it  is  undefined  on  values  and  on  stuck  terms.  Furthermore,  if  the  result  of  any  parallel  reduction  is  a 
value,  the  source  must  have  been  either  a  value  or  a  workable  (Lemma  21).  We  will  refer  to  this  property  of 
parallel  reduction  as  monotonicity . 

6.  Using  the  above  classification,  we  break  our  goal  into  two  cases,  depending  on  whether  the  starting  point  is  a 
value  or  a  workable: 

G1  \fv uv  G  V. 

v  >*  V\  =>  (3^3  eV.V  =  V3^>*  Vi), 

G2  Vw  eW}v£  V. 

w  >*  vi  =>  {3v3  G  V.w  1 — ^  V3  >*  t»i). 

It  is  obvious  that  Gl  is  true.  Thus,  G2  becomes  the  current  goal. 

7.  By  the  monotonicity  of  parallel  reduction,  it  is  clear  that  all  the  intermediate  terms  in  the  reduction  chain 
w  V}  are  either  workables  or  values.  Furthermore,  workahles  and  values  do  not  interleave,  and  there  is  exactly 
one  transition  from  workables  to  values  in  the  chain.  Thus,  this  chain  can  be  visualised  as  follows: 

wi  >  w2  >  ...tite-i  »  wk  >  v  >*  V\. 

We  prove  that  the  transition  Wk  v  can  be  replaced  by  an  evaluation  (Lemma  37): 

R1  Vw  eW,v£  V. 


w  v  =>  {3v2  G  V.  w  1 — V2  ^  v). 

With  this  lemma,  we  know  that  we  can  replace  the  chain  above  by  one  where  the  evaluation  involved  in  going 
from  the  last  workable  to  the  first  value  is  explicit: 


wi  >  w2  >  ...Wk- 1  >  wk  > — v2  >*  v\. 

What  is  left  is  then  to  “push  back”  this  information  about  the  last  workable  in  the  chain  to  the  very  first  workable 
in  the  chain.  This  is  achieved  by  a  straightforward  iteration  (by  induction  over  the  number  of  k  of  workables  in 
the  chain)  of  a  result  that  we  prove  (Lemma  32): 

R2  ,w2  £  W,v  1  G  V . 


w  1  w2 


Vl 


(3v2  G  Y.wi  1 — v2  >  vi). 
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With  this  result,  we  are  able  to  move  the  predicate  _  * — v3  »*  v  all  the  way  back  to  the  first  workable  in  the 
chain.  This  step  can  be  visualised  as  follows.  With  one  application  of  R2  we  have  the  chain: 

W[  >  w2  >  ...wk- 1  > — v3  >*  vi> 

and  with  k  —  2  applications  of  R2  we  have: 


w  i 


Vk  +  l  > 


Wl> 


thus  completing  the  proof. 


□ 


6.3  Push  Back 

Lemma  32  (Push  Back)  VX  E  N,  w\,  W2  E  W,  v<i  E  V. 

x 

W\  W2  I - Y+  V\  =>  (3f2  G  N  .W\  t - Y+  V2  Vl). 

Proof.  The  assumption  corresponds  to  a  chain  of  reductions: 

W\  W>2  ' - Y  W3  I - Y  ...Wk- 1  I - Y  Wk  I - Y  V\. 

Applying  Permutation  to  w\  »  w2  ' — *■  w3  gives  us  (3e2>  G  E.  w\  » — e2#  >  wa)-  By  the  monotonicity  of  parallel 
reduction,  we  know  that  only  a  workable  can  reduce  to  a  workable,  that  is,  (3 w2>  E  Wn.w\  \ — Y+  W2>  ^3)-  Now 
we  have  the  chain: 


Wi  1 - Y+  W2>  >  W3  1 - Y  ...Wk- 1  1 — Y  Wk  ' — Y  V\. 

Repeating  this  step  k  —  2  times  we  have: 

U>i  * - Y+  W2<  ' - Y+  W3>  1 - ...Wk- v  ^  ^  1 — Y  V\  . 

Applying  Permutation  to  ^  ' — Y  v\  give  us  (3e/w  E  E. ly/c-r  1 — ek '  ^i)-  By  the  monotonicity  of 

parallel  reduction,  we  know  that  e^/  can  only  be  a  value  or  a  workable.  If  it  is  a  value  then  we  have  the  chain: 

W\  h— >+  W2>  < — Y+  w3>  1 — ...Wk- v  1 — vk'  >  V\ 

and  we  are  done.  If  it  is  a  workable,  then  applying  Transition  to  Wk>  V\  gives  us  (3v2  E  V.  Wk>  ' — Y+  V2  ^  ri). 
This  means  that  we  now  have  the  chain: 

Wi  I - Y+  W2‘  ' - W31  I - Y+  ...Wk- v  ' - Wk'  1 - Y+  V2  V\ 


and  we  are  done. 


□ 


7  Special  Part  of  Computational  Adequacy  of  Reduction  Semantics 

Remark  33  (Non-termination  and  the  Finiteness  of  Trees)  The  reader  should  be  reminded  here  that  all  the 
structures  that  we  ever  construct  in  this  development  are  finite  trees.  Thus,  non-terminating  computations  are  not 
modelled  by  infinite  derivations,  but  rather,  by  the  absence  of  a  “conclusive”  derivation.  In  particular,  a  big-step 
derivation  is  simply  absent  for  a  “ non-terminating ”  computation,  and  thus,  the  big-step  semantics  identifies  stuck  and 
non- terminating  computations.  Similarly,  a  small-step  derivation  is  ahvays  defined  on  a  non-terminating  computation, 
but  every  finite  sequence  of  small-step  can  be  extended  by  another  step.  Thus,  no  finite  sequence  of  small-steps  leads 
to  a  value  (or  a  stuck  for  that  matter).  Note,  however,  that  the  small-step  semantics  allows  us  to  distinguish  between 
a  stuck  (which  cannot  be  advanced  by  small-step  reduction )  and  a  workable  (which  can  be  advanced  an  arbitrarily 
large  number  of  times  by  small-step  reduction). 


59 


7.1  Evaluation  is  in  Reduction 

Lemma  34  (Evaluation  is  in  Reduction)  Ve  E  E,t>  6  V. 


Proof.  By  a  straightforward  induction  on  the  height  of  the  judgement  e  ^  v. 


1.  ()  -4  ()  and  ()  — (). 

2.  Xx.e  Xx.e  and  Xx.e  — >*  Xx.e 

3.  #z  c— >■  obviously  — >* 

4.  A(#z  x).e  A(#z  x).e  and  A(#z  =>  z).e  — »*  A (#z  =>  z).e. 

5.  A*€L  f  Xi.a  ^  A*G//  /  a:i.c<  and  AzGjL  f  Xj.ei  — »*  A’6L  /  a^.e,- 

ej  A&\e 
e2  <->  e3 

e[.x:  =  e3]  c— »•  e4 

6.  - 

ei  e2  c— >■  e4 

By  induction  hypothesis, ei  — >*  Xx.e,  e2  — 4*  e3  and  e[x:=  63] 
ei  e2  — »*  (Az.e)  e2  — >*  (Az.e)  e3  — ty,  e[x:=  e3]  — >*  e4. 


e4.  Then,  by  compatibility  of 


e4  £->  A(#_  =>  a;).e 

£2  *->•  #-J  =>  63 

e[x:  =  Az'.(&3[#2:  =  a;'])]  e4 

*-*1r - - - 

e4  e2  e4 

/H  H  /f/lj.  /fflj. 

e4  — >*  A(#_  =>  a:).e 
e2  — 4*  #2  =>  fe3 

_ e[x\  -  Ag',(6 3[#2:  -  a:'])]  — >■*  e4 _ 

(A(#_  =>  x).e)  e2  — >*  (A(#_  =>  x).e)  (#2  =>■  63)  — 4/3,  e[x:  =  Ax\63[#z:  =  a:']]  — >*  e4 


:omp.  — 


e4  <-*  A >eLu{fe}  Xj.e,- 

e2  «-4  A-  e4  k  <  n 

efc[a;:  =  e4]  =-4  e5 

- TT - 

ej  e2  ^4  e5 

mil  /hJJ-  mil 

ei  — 4*  Al€iu^l  fi  Xi.Zi 

e2  — >*  /fc  e4  &  <  n 

_ e/;[a!:  =  e4]  — y*  e5 _ 

ei  e2  — >*  (Ai6fulfc)  fi  Xi.ef)  e2  — >*  (Aieir-Ulfc}  fi  Xi.ef)  (. fk  e4) 


efc[a::  =  e4]  — 4*  e5 


lomp _ -IJ- 


ei  c-4  Vi 

e2  *-4  u2 


ei  — r  vi 


_  e2  «-4  u2  ^  e2  — 4  w2 

9.  7 - r - 7 - r  7 - r - 7 - 7 - —7 - -comp.  _•  Jj. 

(ei,e2  ^4  (u1,w2)  (ei,e2)  — 4*  (vi,e2)  — 4*  (wi,v2) 


10. 


11. 


e  M-  (17 ,  v2) 

7Ti  e  >-4  Vi 
e  c— >  (ui,u2)  ^ 
?r2  e  c-4  t>2 
e4  <-4  e2  : 


_ e  — 4*  (ui,u2) _ 

TTl  e  - 4*  JTi  (V!,t)2)  — 4*,  Ul 

e  — 4*  (vi,  v2) 

- 7 - - - co: 

2  e  — 4*  7 r2  (wi,v2)  — v2 


:omp.  — +.♦  If 


comp.  —4*  Jf 


ei  ^  e2  t\  — >  62 

12-  7 - 7 -  7 . . —7 - comp. —*11 

fk  e  1  ^4  /fc  e2  A-  e4  — >•*  /a.-  e2 


13. 


14. 


ei  4t 

#2  =>  e4  <-4  #2  =>  v 
ei-4#2  ^ 

ei^rffz  j£. 


t\  — y  v 


#2  =>  ei  — >*  #2  =>  v 

ei  — >*  #2 
e2  - >*  #2 


comp _ JJ- 


ei  =#  e2  *->  True()  e4  =#  e2  — >*  #2  =  e2  — >*  #2  =  #z  — >#  True() 


;omp.  — 11 
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15. 


16.  ^  - 


ei^#z  ^ 

€2  c-*  #2'  #2  ^  #2'  ^ 

e,  =  e2  ^  False() 

e  ^  #2  : 


ei 

e2 


#2 

#2' 


i7.  -tr  t 


isOVar  e  «->  True() 

e  <— >- 't;  v  ^  #z 


isOVar  e  <— »  False() 


Cl  =#  e2  — >*  #2  =  e2  — >*  #2  =  #2'  - 

_ e  — ►*  #2 _ 

isOVar  e  — >*  isOVar  #2  — >iuov„  True() 
e  — >*  u  i;  ^ 

isOVar  e  — >*  isOVar  u  — >(5is0Var  False() 


-)•#  Fa|se() 

comp.—*.*  ft 
comp _ ►  *  ft 


comp. 


What  is  harder  to  show  is  the  “converse”,  that  is,  that  e  — >*  v  ■ 
stronger  result  of  Lemma  31. 

In  the  rest  of  this  section,  we  present  the  definitions  and  lemmas  mentioned  above 


(3t>'  G  V.e  i/).  It  is  a  consequence  of  the 


7.2  Left  Reduction  is  in  Reduction 

Lemma  35  (Left  Reduction  is  in  Reduction)  Vei,e2  G  E. 

ei  » — ¥  e2  =>  ci  — ¥  e2. 

Proof  (Lemma  35).  Proof  is  straightforward,  by  induction  on  the  height  of  the  first  judgement. 

1.  If  (Ax\e)  v  i — >  e[x :  =  v],  and  (A®.e)  v  — ¥px  e[x:~  v]. 
d  — >  ei  ei  — >  e' 


ei  e2 
e  i — ^  e 


►  ei  e2 

,/  IK 


ei  e2 


ei  e2 


comp _ ^ft 


t;  e 


Cl 


t;  e  — >  v  e 
IK 


j  comp.— ►  ft 


ei 


(ei,e2)  i — >  [e'i ,  e2) 
e  i — ►  e'  — 


(ci}c2)  ^  (e1,e2) 


comp — >-(j. 


2. 

3-  -IT 

4. 

5. 

6-  -ft  ,  __  , 

7Tn  e  i — y  i rn  e  rrn  e  — >  n„  e 

7.  rrj  (vj ,  v2)  ' — >  vi ,  and  rri  (vi ,  v2)  — «i 

8.  ff2  (ui,v2)  ► — >  «2,  and  7r2  (i>i,w2)  — «i 

9.  (Aieiu^'}  fi  Xi.ti )  (/fc  v)  i — ►  e^.[xfc:  =  v]  and  (A’^W  /,•  Zj.e,)  (/*  v)  — yp3  ek[xk:  =  v]. 


(v,e)  i — »  0,e') 
e  i — >■  e' 


(v,e)  — ►  (v,e‘) 


—  comp.-t| 


—  comp.--.JJ. 


10. 


/  e  i — y  f  e' 


/  e  — yfe 


—  comp.--.JJ- 


11.  (A(#2  =>  *).e)  (#2'  =>  6)  1 — ►  e[:r:  =  A x'.b[#z':  =  a:']],  and  (A(#2  =>  x).e)  (#2'  =>  b)  — yp,  e[x:  =  A x'.b[#z':  = 
x1}}. 

P  . i.  o'  J_ H  e  V  p > 

12.  —►•ft  - -  - -  comp.--.JJ. 

13.  #2  =#  2  1 — y  True(),  and  #2  =  #2  — y#  True() 

#2  ^  #2'  ,  #2  ^  #2' 


14. 


#2  =#  2'  1 — >  False() 


and 


#z  =  #zf  — >#  FalseQ 


15. 

16.  ^fr 


Cl 


Cl 


ei  e2 


•  el  =#  e2 

>  e' 


ei  -  e2 


•  cx  =  e2 

.  j 


comp.— *■  ft 


j  comp.— ►  ft 


fjzz1  =#  e  1 — ¥  #z*  =#  c'  =  e  — >  #zf  =  e 

17.  isOVar  #2  1 — >  True()  and  isOVar  — ^(5ii0Var  True() 

18.  If  v  ^  isOVar  v  1 — »  True()  and  isOVar  v  — ^5il0var  True() 

p  , _ L  p'  JA  p  _ A.  p' 

19.  —►'ft  -  - - : - -  comp _ ^ft 

isOVar  e  j — ¥  isOVar  e'  isOVar  e  — ¥  isOVar  e 


□ 
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7.3  Left  Reduction  is  Evaluation 


Lemma  36  (Left  Reduction  and  Big-step  Semantics)  Ve  £  E,  v  £  V. 

e  i — >*  v  <=>  e 

Proof.  The  forward  direction:  Ve  £  E,  v  £  V.e » — u  =>■ 

By  induction  on  the  length  fc  of  derivation  e  i — »*,  and  then  by  induction  on  the  size  of  e.  It  proceeds  by  case 
analysis  on  e. 

-  k  =  0 

1.  For  all  values  v,  v  \ — >*  v,  since  i — >*  is  reflexive.  For  all  other  expressions  e  i — »*  e,  e  is  not  a  value,  and  the 
property  holds  by  contradiction. 

—  h  —  xi  -f-  1 . 

1.  ei  e2  1 — >“  (A*.c)  e2  1 — (Ax.e)  v'  i — e[*:  =  t/]  i — v  where  i  +  j  +  k  =  n.  Then,  by  induction  hypothesis 

e\  < — y  (A:c.e) 
e2  ^4  i/ 
e[x:  = 

- e_j.  4)- 

Cl  C2  <^4 

2.  ei  e2  1 — (A(#_  4>  ®).e)  e2  > — (Aar.e)  (#z  =>  b')  1 — 4  e[x:  =  \x'.b'[#z:  =  a/]]  1 — v  where  i  +  j  +  A  =  n. 
Then,  by  induction  hypothesis 

e\  ^4  A(#_  4>  :c).e 
e2  *4  =>  6' 

e[ar:  —  A£'.6'[#z:  =  z']]  ^4  v 
ei  e2  °4  ^  t~+ 

3.  ei  e2  1 — (Ai€jPu^°l  //  s/.e/)  e2  < — >j  (XleFu^  fi  xi.ei)  (fQ  vf)  1 — e0[x: =  v7]  > — v  where  i  +  j  +  fc  =  n. 
Then,  by  induction  hypothesis 

ci  <-4  (Af€Fu^°J  fi  xi.ei) 

C2  <4-  /0  v7 
ei[x\~  v*]^v 
t\  e2  4  v 

4.  (ei,e2)  1 — >*  (vi ,  e2)  1 — >3  (vi,v2),  where  f  +  j  =  n  +  1.  Then,  by  the  induction  hypothesis 


ei  <->vi  e2  ^4  v2 


4 


5.  7T 1  e 


(ci,e2)  c4  (vi,  v2) 

>n  7T 1  (^1 ,  Vo)  1 — >-1  v\.  For  each  step  in  the  n  first  reductions,  clearly  the  same  rule  of  the  left  reduction 


applies,  namely 


—  Thus  it  easily  follows  that  e  1 — >n  (t>i,  u2).  Applying  the  induction  hypothesis 


tti  e  1 — )•  tt\  e 

to  this  result,  we  obtain  e  ^4  (i?i,t>2).  By  definition  of  <-4,  from  this  follows  7Ti  e  *-4  V\. 

6.  7 r2  e  1 — *n  7t2  (vi,  V2)  1 — 4  v2.  For  each  step  in  the  n  first  reductions,  clearly  the  same  rule  of  the  left  reduction 


applies,  namely 


— .  Thus  it  easily  follows  that  e  1 — 4  (t^,  u2).  Applying  the  induction  hypothesis 


7 r2  e  1 — >  7t2  e' 

to  this  result,  we  obtain  e  4  (ui,  u2).  By  definition  of  <^4,  from  this  follows  ?r2  e  4  i>2. 


7. 


8. 


ci 


v  n  +  1 


Cl 


/*  c  1  l 

_ >71  -{- 1 


>n  +  l 


/  V 


ei  4r 
/ei4/v 

ei  4  ^ 


#z  =>  ei  1 — >n+1  #z  v  #z  =>  ei  ^4  #z 


9.  ej  =  e2  i — #z  =  e2  1 — #z  =  #£  > — ^  True,  where  i  +  j  =  n.  Then,  by  the  induction  hypothesis 

ei 

ex  —  e2  <-)■  True() 


10.  Similarly, 

ei  =  e2  i — #2  =  e2 


#z  =  #z'  1 — False,  where  i  +  j  =  n.  Then,  by  the  induction  hypothesis 


ci  ^  #* 
62  ^  #*' 


ei  =  e2  ^  False() 

yl  isOVar  #2  • — y1  True(),  then  e  1 — >*  #z.  By  the  induction  hypothesis  e  c— >•  #z.  Then,  isOVar  e 
isOVar  v  1 — FalseQ,  then  e  1 — y%  v.  By  the  induction  hypothesis  e  v.  Then,  isOVar  e  <-* 


11.  isOVar  e  1 
True(). 

12.  isOVar  e 
False(). 

The  backward  direction:  Ve  E  E.  Vu  E  V.e  v  ==>  e  1 — v.  By  induction  on  the  height  of  the  derivation  of 
e  <-y  t>,  and  then  by  the  size  of  e. 

1  (FTU 


2. 


and  Az.e  1 — >°  Az.e. 


3. 


4. 


Ax\e  Ax.e 
ei  Aa:.e 
62  ^  63 
e[ar.  =  63]  e— >■  e4 
ei  c2  c— > 

e[ar:  =  u]  « — e4. 

ei  M-  A^GjLu^^(/  xj)xj 

62  e— ►  A  64 

e/,[a;:  =  e4]  ^  e5 _ 

ci  e2  e5 


61 


(A&\e) 


By  induction  hypothesis:  e2 


.  Then,  ei  e2  • — (Xx.e)  e2  1 — y3  (Xx.e)  v 


e[x:  —  e3]  \ — yk  e4 


61 


A *€Lu{k}y  Xjyej 


.  By  induction  hypothesis:  e2  ' — y3  k  e4 

ek[x:  =  e4]  1 — yl  e5 


Then,ei  e2 


(A i€Lu{k}(f.  Xiyei)  e2 


5. 


{XieLu{k}(fi  Xi).ei)  (k  e4)  1 — y1  e*[a:  =  e4]  »— ►*  e5. 

61  <->■  A(#_  =>  ;r).e 

e2  «->*  63 

e[a:  =  Aad.  (fr3[:#:z:  =  a;'])]  ^  e4 

6]  62  c— >  €4 

ei  ( — yl  A(#_  =>  x).e 

By  the  induction  hypothesis  e2  1 — y3  #z  =>  &3 

e[z:  =  Ax/.(63[#z:  =  s'])]  1 — ¥k  e4 

Then,  e:  e2  1 — yx  (A(#_  =>  z).e)  e2  * — y3  (A(#_  =>  a?).e)  (#2  63) 


[ar:  =  A x* .b[#z\  =  a?']]  1 — yk  e4. 


6.  61  —  "3 — -7  —  ^  By  the  induction  hypothesis  61  ’  ^  63 

(ei,e2)  (e3,e4)  e2  ^  e4 


Then,  (ei,e2) 


(e3,e2)  1 — y3  (e3,e4). 


7.  6  —  -  3l  — .  By  the  induction  hypothesise  1 — yn  (e3,64).  Then,  tvx  e  \ — yn  nx  (e3,e4)  1 — )-1  e3. 

7r x  €  c — y  e3 

^  r  ^  ^  g 3  j 

8.  -  -.  By  the  induction  hypothesis:  e  1 — >n  (e3,e4).  Then,  7 r2  e  1 — yn  7r2  (e3,e4)  1 — ^  e4. 


9. 


10. 


11. 


tt2  g  c — e4 

ci  ^  e2 

A  ei  ^y  A  62 


A ieLfi  Xi.ei  Ai€L/2-  a?2-.ei 


By  the  induction  hypothesis  ei  1 — >n+1  e2.  Then,  /  ei 
and  XteLfi  Xi.ei  1 — A ieL fi  a^.e*. 


v«  +  1 


/  C2. 


e  >■  v 


12.  #2:  #z,  and  1 — #z 


By  the  induction  hypothesis  e  1 — ^n+1  u.  Then,  #z  =>  e  1 — >-n+1  =>  v. 


63 


13.  A (z  =>  x).e  ^  A (z  x).e ,  and  A (z  =>  x).e  \ — >°  A(z  x).e. 

ei^#^ 

14.  - ^  .  By  the  induction  hypothesis:  61  '  ^7  .  Then,  ei  “#  e2  i — >*  =#  e2  1 — — # 

ei  e2  c__).  True()  e2  ' — r  #z 

#z  i — yl  True(). 

ei  ^  #z 

t%  ^  #z' 

^j:  p  zjz  )) z  i p 

15.  - — — — .  By  the  induction  hypothesis:  ,■  .,  ..  Then,  ei  =#  e2  ' — ►’  #z  =#  e2  • — ^  #z  =# 

e,  =#  e2  °4  True()  e2  ■ — r  #z  " 

#z'  h-^1  False(). 

16.  Rulee  t-4  #zisOVar  e  ^4  True()  By  the  induction  hypothesis:  e  i — >*  #z.  Then,  isOVar  e  i — >*  isOVar  #z  t — > 
True(). 

17.  - —  By  the  induction  hypothesis:  e  h — »*  v  (and  v  /  #z).  Then,  isOVar  e  h— »*  isOVar  i>  i — > 

isOVar  e  ^  False() 

False(). 

7.4  Transition  Lemma 

Lemma  37  (Ti*ansition)  VA  G  N.  Vu?  G  IT,  v  G  V. 

w  v  ==>  3v2  G  V,  y  G  N.  it?  i — »+  v2  v  A  Y  <  X. 

Proof  (Lemma  37 (Transition)).  Proof  is  by  induction  on  the  complexity  A,  and  then  on  the  structure  of  w. 


1.  For  the  workable  (\x.e)  v% 


M  /  N 
e  e  v  v 

~  "  M+#(.r,e,)N+l  7 

(Xx.e)  v  e  [a::  =  v  J 


M  N  Z 

Since,  e  ^  ef  and  v  t/,  then  by  lemma  18,  3 Z.e[x:=  v\  e7[x:  =  vf]  A  Z  <  M  ff(x,e')N .  Now,  there  are 

two  possibilities. 

(a)  First,  if  e[x:=v]  is  a  workable,  then  since  Z  <  M  +  #(x,e7)A  +  1,  the  induction  hypothesis  applies  to 

e[x:  =  u],  and  therefore:  3vj  3Yi  .e[x:  =  v]  i — vi  e7[x:  —  v7]  A  Yi  <  A  Thus,  we  obtain  our  goal  as  follows: 
3v2  =  vl.3Y  =  Y1. 

(Xx.e)  v  i — >l  e[x:  —  v]  \ — >+  v2  e[x\  ~  v']  A  Y  <  M  +  #(#,  e7)  A  +  1 

(b)  Otherwise,  if  e[x:  =  v]  is  a  value,  then  3v2  =  e[x:  =  v].3Y  =  Z. 


(Xx.e)  v  — ^  e[x:  =  v]  »  e'[x:  =  v7]  A  Y  <  M  +  #(s,  e7)A  +  1 


M 

e  »  e 


_  _  _  M 

2.  For  the  workable  (A(#_  =>  x).e)  (#4  b)  - yy— -  .  Since  e  e 

(A(#_  x).e)  (#z  b)  e;[o::  =  Ax^^f#^:  =  x']] 

and  A xf .b[#z:  =  x'}  Ax'.6[#^:  =  x7],  by  lemma  18  3Z.  e[x:  =  A xf.b[#z:  =  x']]  e7[x:  =  Ax' .b[#z:  =  x']]AZ  <  M . 

Again,  there  are  two  possibilities 

(a)  e[x:=  Xx/ .b[))z:  —  x']]  is  a  workable.  Then,  since  Z  <  M  +  1,  the  induction  hypothesis  applies  and  we 

y 

obtain  3v\ .  3Y\.  e[x:  =  Ax'.6[#2::~  x']]  »— >+  e7[x:=  Ax7.6[#z:=  x7]]  AY\  <  Z.  Then,  it  easily  follows 

3v2  =  t;1.3y  =  yi., 

(A (#_  =>  x).e)  =>  6)  1 — J-1  e[x:  =  Ax7.6[#z:  =  x7]]  1 — v2  e7[x:  =  Ax7.6[#z:  =  x7]]  AY  <  M  +  1 

(b)  Otherwise,  e[x:  =  Ax7.6[#2::  x7]]  is  a  value.  Then,  3u2  =  e[x:  =  Ax1  .b[#z:  =  x7]].  3Y  =  Z. 

(A(#_  x).e)  (#z  b)  1 — y1  e[x:  =  Ax7.6[#z:  =  x7]]  e7[x:  —  Ax7.6[#r:  =  x7]]  A  Y  <  M  +  1 


64 


3.  The  workable  w  e  can  never  parallel-reduce  to  a  value  in  one  parallel  reduction  step,  so  the  property  vacuously 
nolds. 

4.  Similarly,  the  workable  v  w  can  never  parallel-reduce  to  a  a  value  in  one  parallel  reduction  step,  so  the  property 
vacuously  holds. 


5.  For  the  workable  f  tv, 


x 

W  V 

~  x 

J  W  V 


Yi 


By  the  induction  hypothesis  3vx  .  3Yi .  tv  ■ — y+  v2  >  v  A  Yi  <  X.  Then,  it  easily  follows  that  3v2  =  /  vx .  3Y  =  Yx. 


f  w  t — y+  fv2>fvAY<X 


6.  For  the  workable  =>  tv, 


M 

W  V 


M 


=>  W  >  #Z  =»  V 


n 


Then,  by  the  induction  hypothesis,  3vi.3Yi.it>  i — v\  v  A  Yx  <  M . 

Then,  it  easily  follows  that  3v2  =  #z  v\.  3Y  —  Y\.  (#z  tv)  i — y+  v2  (#z  =>  v)  A  Y  <  M. 

M  N 

w  v %  e  v2 

7.  For  the  workable  (tv,e),  — 


M+N 

(w,e)  >  (t>i,v2) 


Yi 


Then,  by  the  induction  hypothesis  3v3.3Yi.it; » — >+  v3  %>  vx  A  Yx  <  M . 
From  this  it  easily  follows:  3v^  =  (V3,  e).  3Y  =  Yi  +  N. 


(tv,e)  > — (v3,e)  >  (vx,v2)  A  Y  <  M  +  N 


8.  For  the  workable  (v,tv), 


M  N 

v  >  vi  it;  >  v2 

M+N  ~ 
(v,iv)  »  (VuV2) 


Yx 


Then,  by  the  induction  hypothesis:  3v3.3Yi.iv  i — y+  v3  %  v2  A  Y  <  N. 
From  this  it  easily  follows:  3v3  =  (v,  v3).  3Y  =  M  +  Yi. 


(v,  tv)  i — y+  (v,  v3)  >  (vx ,  v2)  A  Y  <  M  -f  N 

9.  For  the  workable  tv  =  e,  it  is  easy  to  show  that  it  can  never  be  parallel-reduced  in  one  steps  to  a  value,  so  the 
property  holds  vacuously. 

10.  Similarly  for  the  workable  #z  =  tv  it  is  easy  to  show  that  it  can  never  be  parallel-reduced  in  one  step  to  a  value, 
so  the  property  holds  vacuously. 

11.  For  the  workable  #z  =  #z',  #z  =  #z'  >  TrueQ  if  #z  =  #z'.  Then,  obviously,  3v2  =  True().3Y  =  0.  #z  = 

#z'  i — y1  True()  True()  A  0  <  1. 

12.  For  the  workable  #z  =  #z',  #z  —  #z'  >  False()  if  #z  /  #z'.  Then,  obviously,  3v2  =  False().3Y  -  0.#z  = 
#z'  i — False()  FalseQ  A  0  <  1. 

13.  For  the  workable  7Ti  tv,  it  is  easy  to  show  that  they  could  never  reduced  in  one  step  to  values  by  a  single  parallel 
reduction  step,  so  the  property  vacuously  holds. 

14.  For  the  workable  7 r2  tv  it  is  easy  to  show  that  they  could  never  reduced  in  one  step  to  values  by  a  single  parallel 
reduction  step,  so  the  property  vacuously  holds. 

M  , 

15.  For  the  workable  7Ti  (vx  ,  v2),  - - - -  .  Then,  3v2  =  vx.3Y  —  M.  tti  (vi,  v2)  i — y1  vx  AY  <  M+ 1. 


,  ,  M+l 

tti  (vuv2)  »  v[ 


M 


16.  For  the  workable  7 r2  (vi ,  v2), 


V2  >  v'2 


Then,  3v2  —  v2. 3 Y  —  M.  7 r2  (vi,  v2)  i — y1  v2  vf2AY  <  M+l 


,  .  M+i  . 

K2(Vl,V2 )  »  V2 


17.  For  the  workable  isOVar  #z,  isOVar  #z  ^  True().  Then,  3v2  =  True().3Y  —  0.  isOVar  #z  i — True() 
True()  A  Y  <  1. 


18.  For  the  workable  isOVar  v ,  where  v  ^  ifz,  isOVar  v  False().  Then,  3vo  —  False().3y  —  O.isOVar  v  \ 
False()  False  A  Y  <  1. 

19.  For  the  workable  isOVar  w  it  is  easy  to  show  that  it  could  never  be  reduced  to  a  value  in  a  single  parallel-reduction 
step,  so  the  property  vacuously  holds. 

□[e.p-j 


7.5  Permutation  Lemma 

Lemma  38  (Permutation  )  MX  G  f^.Mw\iw2  E  Wye\  G  E. 

X  _ 

w\  102  1 — ►  ei  =>  (Be2  G  E.  wi 

Proof  ( Lemma  38).  MX  G  N.Viui,ttf2  E  G  E. 


e2  >  ei). 


x 

W\  IVo 


d  =>  (3e2  G  E.  u>i 


e2  »  ei). 


Proof  is  by  induction  on  the  complexity  X  of  derivation  wi  >  wi,  and  then  my  the  size  of  wi.  Proof  proceeds  by 

x 

case  analysis  over  derivation  of  w\  ^  w2- 


,  and  ef[x:  = :  ?/]  i — >  ei. 


M  tv  . 

e  e  ^ 

1.  For  the  workable  (Ax.e)  v,  - __ ,  — 777777 — 

M  +  #(x,e')iV+ 1 

(Aa,\e)  v  >  e'[:r:=i/] 

jy+^(r,e/)A^ 

By  Lemma  18,  e[x:  -  v]  >  e'[x:  =  u7].  Since  M  +  #(s,  e7)fV  <  M  +  #(ar,  e7)N  +  1,  and  by  monotomcity 

properties  ef[x:  —  vf]  is  a  workable,  then  the  induction  hypothesis  can  be  applied  to  e[x :  =  v]  to  obtain:  3e2.e[au  = 

v]  1 — eo  e\.  Then,  it  easily  follows:  E3e3  —  e2.(Aa?.e)  v  » — f1  e[x:~  v]  1 — e3  ei. 

M 

e>>e 

2.  For  the  workable  (A(#_  =>  x).e)  (#z  =>  6), 


(A(#-  =F  x).e)  (: #z 


b)  A>1  el[x:  =  A x' .b[#z:  =  a:7]] 


Cl 


By  Lemma  18,  3Z.e[au  =  Aa:7.&[#z:  =  a:7]]  >  el[x\  =  \x* .b{#z\  =  or7]]  A  Z  <  M.  Then,  by  the  induction  hypothesis: 
3e2.  e[au  =  A xl .b[#z:  =  a:7]]  1 — e2  >  ei.  Then,  it  immediately  follows  3e3  =  e2.  (A(#_  =>>  a?).e)  (#z  =>  6)  1 — 
e[a;:  -  Aa:7.6[#2:  =  a:7]]  * — >+  e3  >  ei. 


M+N 

3.  For  the  workable  w\  e  w[  e 


ei, 


M  N 

wx  w\  e  >  e7 


M+N  • 

e  e 

There  are  five  possibilities,  and  they  all  must  be  examined. 

X  M 

(a)  tui  ei  >  w[  e[  \ — >  e2  e[  By  definition  of  >,  wi  >  w[ ,  and  w[ 

3t3.w\  y — e3  e2.  Then,  3e4  =  e3  ei.tui  e\  1 — >+  e4  e2  e[. 

x 

(b)  w  e  ^  v  w*  1 — >  v  w/f  By  definition  of  e  wl y  and  by  definition  of 
monotonicity  of  ^>,  e  must  be  a  workable,  and  the  induction  hypothesis  can  be  applied  to  it:  3e3.e 
e3  wft .  Since  w  >  u,  then  by  transition  lemma:  3u2.w  * — V2  v.  Then,  3e4  =  v2  e3.i^  e  1 — >+ 

v2  e  1 — >*+  v2  v  w". 

x 

(c)  w  e  (Ax.ei)  v  1 — >  ei[x:  =  v]  There  are  two  possibilities: 

i.  e  G  V.  Then,  applying  transition  to  w  gives:  3^2  =  A x. 64.10 
(Ax.e4)  e.w  e  1 — >+  (Ax\e4)  e  e\ [au  =  c]. 

ii.  e  G  W.  Then,  transition  can  be  applied  to  both  w  and  e,  to  obtain  3i>i  =  Xx. 64.10  1 — A,r.e4  Ax.ei 
and  3v2.e  1 — v2  v.  Then  3e5  —  v\  v2.w  e  1 — Vi  e  1 — >+  vi  v2  e[x:~  v\. 

(d)  w  e  >  (A(#z  =>  a:).ei)  (#z  =>  6)  i — >•  ei[ar:  =  \xf .b[#z:  =  a:7]]  Similar  to  previous  case. 

(e)  w  e^>  (A f£Fu{k)  f  xj.ej)  (k  v)  \ — >  e[x :  =  v]  Similar  to  previous  case. 

4.  For  the  workable  v  wy  there  are  four  cases: 

(a)  v  w  vl  wf  1 — >  v'  w 77  Then,  by  definition  of  v  v 7  and  u;  w* .  By  the  induction  hypothesis  we 

>+  e2  w" .  Then,  3e3  =  v  e2-  v  to  1 — v  e2  vf  wn . 


e2  Then,  by  the  induction  hypothesis: 


also  w 7  1 — >  u;77.  Then,  by 

+ 


(Ax\e4)  (Aaj.ei).  Then,  3e3 


have:  3e2*^  1 


» 


5. 

6. 
7. 


8. 

9. 


10. 


11. 


12. 


13. 

14. 

15. 

16. 


(b)  (Xx.ei)  w  >  (Aai.e,)  v  i — ¥  e, [a; :  =  v]  Since  w  >  v,  we  can  apply  transition  lemma.  Thus,  3v2.tu  ' — 
v2  >  w. 

Now,  3e2  =  {Xx.ei)  v2.  (Xx.ei)  w  > — ¥+  (Aar.ei)  v2  ■ — t1  ei[x:=  v2).  Then,  by  the  subsituttion  lemma: 

ei[x\  =  r>2]  e'i[x:  =  u],  since  e\  ei  and  v2  >  v. 

M +N 

(c)  (A (#z  =>  x).ex)  (#z  =>  w)  »  (A (#2  =>  xJ.e'j)  (#2  =>  6)  i — ¥  e[[x:=  Xx.b[#z:  =  a:']]  Similar  to  previous 


case. 

(d)  (A'f€Fu^^  /  Xf.ej)  ( k  w)  »  (A^eFu<fc}  /  xj.e'j)  ( k  v)  > — ¥  e'k[x\  =  u]  Similar  to  previous  case. 
f  w  >  f  w*  I — /  e  Then,  by  the  definition  of  >,  w  >  iy'  i — >  e. 

By  the  induction  hypothesis,  3ei.it;  i — >+  e\  >  e.  Then,  3e2  —  f  e\.  f  w  \ — ¥+  f  e\  >  /  e. 

=>  it;  >  #2  =>  it;'  i — »  =>  e.  Then,  by  definition  of  iy  >  it;'  i — >-+  e.  By  the  induction  hypothesis 

3ei.it'  i — ei  e.  Then,  3e2  =  =>  ex .  =>  it;  > — #2  =>  e  1  ^  =>  e. 

For  the  workable  (iy,e)  there  are  two  possibilities: 

(a)  (it;,  e)  (ty',e')  1 — >  (iy",e')  Then,  by  the  induction  hypothesis:  3ei.iiM — e\  >  iy". 

Then,  3e2  =  (ei,  e).  (iy,  e)  1 — (ei,  e)  >  (it;",  e'). 

M+ N 

(b)  (iy,e)  >  (y,iy')  1 — ¥  (y,iy").  Then,  e  must  be  a  workable,  and  e  >  it/  1 — ¥  w" .  Thus,  by  the  induction 

hypothesis  3ei.e  1 — e\  iy".  Furthermore,  by  the  transition  lemma:  3v\.w  • — ¥+  v\  0. 

Then  3e2  =  (ex,0x).  (iy,e)  1 — (01,  e)  1 — (01, ex)  »  (0,ty"). 

For  the  workable  (0,1 y),  where  (v,w)  >  (y',iy')  1 — ¥  (0' ,«/").  By  the  induction  hypothesis  3ei.it;  1 — ¥+  ei  >  wn . 
Then  3e2  —  (y,  ei).  (y,  it;)  1 — ¥+  (0,  e\)  >  (y',  ty"). 

For  the  workable  iy  =  e,  there  are  four  possibilites: 

(a)  it;  =  e  it;'  =  e'  1 — ¥  iy"  =  e'  Then  w  wf  \ — ¥  it;".  By  the  induction  hypothesis:  3ei.  iy  1 — *-+  ei  iy". 

Then  3e2  =  (ei  =  e).  iy  =  e  1 — >+  e\  =  wn  ~  e' . 

(b)  it;  —  e  #z  =  iy'  t — ¥  #z  =  ef  By  transition  lemma  3i;i.iy  1 — v\  #z.  Since  e  iy',  by  transitivity 

properties  of  e  must  also  be  a  workable,  and,  as  iy'  1 — ¥  e',  the  induction  hypothesis  applies:  3ei.e  1 — 
ex  e'.  Then  3e2  =  (vt  =  e\).  w  =  e  1 — v\  —  e  1 — v\  =  ex  #2:  =  e'. 

(c)  w  =  e  ^  #z  =  #z  1 — >  True()  By  transition  lemma  and  properties  of  parallel  reduction,  w  1 — >+  #z  and 

e  1 — #z.  Then  it;  =  e  1 — #z  —  e  1 — )-+  #z  =  True(). 

(d)  w  —  e  1 — >  False()  By  transition  lemma  and  properties  of  parallel  reduction,  iy  y — and 

e  i — ¥+  #z'.  Then  w  —  e  1 — —  e  1 — )-+  =  #zf  False(). 

For  the  workable  #z  —  iy, there  are  three  possibilities: 

(a)  =  w  i — ¥  #z  =  iy'  1 — >  #z  —  iy".  By  the  induction  hypothesis,  3ei.iy  > — ei  iy".  Then  3e2  =  (#z  = 
ex).  -  it;  1 — #z  =  ei  >  #2:  =  iy". 

(b)  =  it;  1 — »  #2:  =  1 — >  True()  By  the  transition  lemman  3y.iy  1 — v  #z..  But  v  must  be  #z,  if  it 

parallel  reduces  to  #2.  So,  3e2  =  (#z  =  #z).#z  =  w  * — #2  =  True(). 

(c)  —  it;  1 — »  =  #zf  1 — >  False()  By  the  transition  lemman  3u.ty  1 — i;  #zf..  But  v  must  be  #2:',  if  it 

parallel  reduces  to  #z'.  So,  3e2  =  (#2:  =  #2:').  =  w  1 — )-+  #2:  =  #z'  False(). 

For  the  workable  #2:  =  there  are  two  possibilities: 

(a)  #z  =  #2:'  1 — >  True().  Obviously  3ex  =  True().  #2  —  #z'  1 — True()  >  True(). 

(b)  #2;  =  1 — )■  False().  Obviously  3ei  =  Fa!se().  #2:  =  #z'  1 — )-+  False()  False(). 

For  the  workable,  7Tx  iy  there  are  two  possibilities: 

(a)  7Ti  iy  7Tx  iy'  1 — >  7Tx  iy".  Then,  by  the  induction  hypothesis,  3ei.iy  1 — )-+  ei  iy".  From  this  it  easily 
follows  3e2  =  7r  1  ex .  7Tx  iy  1 — 7Tx  ex  7Ti  iy". 

(b)  7T x  u;  7r  1  (ui,y2)  1 — V\.  Then,  by  transition  lemma,  3y3.iy  1 — >+  (^3,^4)  (^1,1^2)-  Then,  3e2  = 

7Ti(v3,  V4).  7T 1  iy  1 - ¥+  7T 1  (1/3,04)  >  01 

The  case  for  1 r2  is  sy metrical  to  the  case  above. 

For  the  workable  7Tx(yi,  y2)  7r2(yx,y2)  1 — *  vi-  Then  01  y'x . 

3e2  =  v\.  n-i  (ui,u2)  t — ¥1  vx  »  v(. 

For  the  workable  7t2(ui,u2)  •k2(v']l,v^)  > — ¥  v'2.  Then  v2  v'2. 

3e2  =  u2. 7r2  (ui  ,  v2)  1 — J-1  w2  »  v2. 

For  the  workable  isOVar  #2,  isOVar  #2  isOVar  #2  1 — ¥  True().  Then  3e2  =  True().  isOVar  #2  1 — e2 
True(). 
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17.  For  the  workable  isOVar  v, where  v  ^  z ,  isOVar  v  isOVar  vf  > — >  FalseQ.  Then  3e2  =  FalseQ.  isOVar  v  i — 

e2  >  False(). 

18.  For  the  workable  isOVar  w ,  there  are  three  possibilities: 

(a)  isOVar  w  >  isOVar  ffz  i — »  True().  By  definition  of  >,  w  >  #r.  By  transition  w  \ — #z.  Then  3e2  = 

True.  isOVar  if « — )-+  isOVar  i — >  e2  True(). 

(b)  isOVar  w  isOVar  v  i — >  False(),  where  f  7^  By  definition  of  ^>,  w  v.  By  transition  3i/.  w  1 — v'  f . 

Then  3e2  =  False().  isOVar  w  1 — isOVar  1/  \ — >  e2  ^  False(). 

(c)  isOVar  w  isOVar  if'  1 — >  isOVar  if".  By  definitions  of  and  1 — >,  if  in'  1 — *  if".  By  the  induction 
hypothesis,  3e.  w  \ — e  ^  if".  Then,  3e2  =  isOVar  e.  isOVar  if  1 — isOVar  e  isOVar  if". 

□  [e.p.] 
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Abstract 

The  use  of  domain  specific  languages  (DSLs)  and  advanced  programming  language  type  systems  can 
have  a  significant  effect  on  programmer  productivity  and  software  quality.  However,  the  high  cost  of 
designing  a  type  system  and  the  limited  user  community  of  a  DSL  makes  it  economically  infeasible  for  us 
to  design  typed  DSLs  and  take  the  advantage  of  both.  In  this  paper,  we  address  this  problem  by  reducing 
the  effort  that  is  needed  to  build  type  systems. 

Most  current  type  systems  are  designed  in  a  monolithic  fashion— with  several  language  features  mixed 
up  together  in  a  single  block — which  can  make  them  hard  to  understand,  hard  to  reuse,  and  hard  to  extend. 
In  this  paper,  we  show  a  way  of  building  type  systems  in  a  modular  fashion  by  composing  independent  and 
reusable  building  blocks,  each  of  which  implements  one  particular  type  feature.  Using  this  way,  building 
type  systems  becomes  as  simple  as  properly  selecting  and  composing  building  blocks. 

The  work  presented  here  is,  to  our  knowledge,  the  first  attempt  to  build  type  systems  in  a  compositional 
style.  Technical  contributions  of  this  work  include  a  novel  use  of  rank-2  polymorphism,  and  the  introduction 
of  a  new  form  of  map  operator  over  abstract  syntax. 


1  Introduction 

One  of  the  goals  of  programming  language  research  is  to  design  languages  that  will  enable  programmers  to 
develop  code  more  efficiently,  while  also  producing  more  reliable  software  systems.  Domain  specific  languages 
(DSLs)  and  programming  language  type  systems  are  two  distinct  threads  of  current  research  that  potentially 
realize  this  goal.  The  strengths  of  DSLs  are  in  allowing  programmers  to  work  at  a  higher  level,  using  the 
familiar  abstractions  and  notations  with  which  they  are  already  familiar  instead  of  the  constructs  of  a  general 
purpose  language.  The  strengths  of  programming  language  type  systems  are  in  helping  to  guarantee  type-safe 
execution,  to  justify  code  optimizations,  and  to  document  programmers’  intentions.  Each  of  these  can  have 
a  significant  effect  on  programmer  productivity  and  on  the  quality  of  the  final  product.  It  follows  that  typed 
DSLs,  offering  the  benefits  of  both  in  a  single  language,  would  make  particularly  attractive  tools  for  a  wide 
range  of  programming  tasks.  However,  DSLs  usually  only  have  a  limited  range  of  users,  while  building  type 
systems  usually  require  a  lot  of  effort.  So  the  high  starting  cost  makes  it  economically  infeasible  to  build  a 
type  system  for  each  DSL. 

In  this  paper  we  propose  a  possible  solution  to  address  the  problem  by  trying  to  reduce  the  efforts  to  build 
type  systems.  Traditionally,  type  systems  are  built  in  a  monolithic  fashion,  with  all  the  type  features  mix 
together  in  a  single  block.  This  way  of  building  type  system  makes  them  hard  to  reuse  and  hard  to  extend. 
We  propose  an  innovative  approach  to  build  reusable  type  systems  in  a  modular  fashion.  The  key  idea  is  as 
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follows:  we  design  some  independent  and  reusable  type  system  building  blocks,  each  of  which  has  a  standard 
interface  for  extension,  and  each  of  which  implements  one  particular  type  feature,  such  as  primitive  types, 
A-calculus[l],  polymorphism^],  etc;  when  we  want  to  build  a  type  system,  we  first  select  the  type  system 
building  blocks  that  implement  the  type  features  we  desire  to  have,  and  then  compose  them  by  their  standard 
extension  interface  to  obtain  the  type  system  as  needed.  By  this  means,  it  becomes  more  easier  to  build  a 
type  system,  and  makes  it  economically  feasible  to  build  typed  DSLs. 

The  approach  of  building  modular  type  systems  also  brings  other  advantages  besides  the  principle  motivation 
of  offering  an  economical  way  of  building  typed  DSLs. 

•  Modular  type  systems  are  easier  to  understand.  It  is  often  easier  to  understand  several  small  simple 
blocks  than  to  understand  a  big  complicated  one. 

•  Modular  type  systems  enhance  reusability.  The  building  blocks  of  a  modular  type  system  are  designed 
with  a  standard  interface  for  extension,  so  they  can  be  easily  reused  in  other  settings.  The  type  features  in  a 
monolithic  type  system  are  tightly  coupled  together,  so  it  is  hard  to  abstract  them  out  of  the  fiamework  and 
make  them  reused. 

•  Modular  type  systems  are  easier  to  extend.  To  extend  a  modular  type  system,  we  just  need  to  design 
a  new  building  block  for  the  newly  added  type  feature,  and  compose  it  with  the  original  type  system  using 
its  standard  extension  interface;  however,  to  extend  a  monolithic  type  system,  we  usually  need  to  modify 
the  overall  system,  and  carefully  fit  the  new  type  feature  in  such  that  it  interacts  correctly  with  the  existing 
framework. 

•  The  framework  of  modular  type  systems  can  help  to  study  the  interaction  between  type 
features.  The  interaction  between  type  features  are  reflected  in  the  different  results  obtained  by  composing 
the  same  set  of  building  blocks  in  different  orders. 

In  Section  2,  we  will  show  how  to  build  a  modular  type  system  in  a  compositional  style  for  a  simple  toy  DSL; 
in  Section  3  and  Section  4,  we  will  give  a  modular  implementation  for  the  type  system  described  in  Section  2, 
where  Section  3  deal  with  syntactic  problem  and  Section  4  deal  with  static  semantics  problem;  in  Section  5, 
we  will  discuss  some  related  works  of  this  paper;  finally  in  Section  6,  we  draw  a  conclusion  and  sketch  some 

future  work. 


2  Type  Systems  in  a  Compositional  Style 

We  consider  a  programming  language  type  system  to  be  a  combination  of  two  components:  syntax  and  static 
semantics.  Syntax  consists  of  expression  syntax  and  type  syntax  of  the  programming  language,  and  static 
semantics  is  a  typing  relationship  between  these  two  kinds  of  syntaxes.  An  expression  is  said  to  be  well-typed 
if  there  exists  a  type  associated  with  it  in  the  static  semantics;  otherwise  it  is  ill-typed.  Normally  the  static 
semantics  are  delineated  by  a  set  of  axioms  and  inference  rules.  An  expression  is  said  to  be  of  a  certain  type 
if  there  exists  a  typing  derivation  using  the  typing  rules  asserting  that.  In  this  paper,  we  only  consider  the 
case  that  the  typing  relationship  is  functional  from  the  expression  syntax  to  the  type  syntax,  so  we  will  focus 
on  type  checking  functions  for  static  semantics. 

In  this  section  we  will  show  an  example  of  building  a  modular  type  system  for  a  simple  toy  language  in 
a  compositional  style.  This  will  be  done  in  three  steps,  each  of  which  is  associated  with  a  particular  type 
feature.  Then  we  will  extract  a  pattern  of  modularity  from  the  example. 
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2.1  A  Type  System  for  the  Language  of  Integer  Arithmetic 


We  will  first  introduce  the  type  system  for  a  very  simple  language:  integer  arithmetic.  In  this  language, 
there  are  only  two  kinds  of  expressions:  integer  constants  and  addition  operations,  and  one  type:  Int.  The 
expression  syntax  and  type  syntax  are  defined  by  context  free  grammar  as  follows: 


expression  syntax  :  E 

Integer E 


Integer E 
n 


E  +  E 


type  syntax  : 


T  =  IntegerT 

IntegerT  =  Int 


In  these  definitions,  E  stands  for  the  expression  syntax,  while  T  stands  for  type  syntax.  Note  that  currently, 
E  only  includes  IntegerE,  which  stands  for  the  expression  syntax  for  integer  arithmetic;  T  only  includes 
IntegerT ,  which  stands  for  the  type  syntax  for  integer  arithmetic.  In  later  sections,  we  will  see  that  both  E 
and  T  will  get  extended  with  more  syntax  structures.  In  the  definition  of  E,  n  stands  for  integer  constants. 
Having  shown  the  syntax,  we  show  the  inference  rules  for  type  checking  the  expression  syntax  constructs. 


-  ( integer  constant ) 

T  b  n  :  Int 


r  I—  £7i  :  Int  T  b  E2  :  Int 
r  b  E\  +  E2  :  Int 


(1 addition  operation ) 


The  integer  constant  rule  means  that  any  integer  constant  is  of  type  Int ;  the  addition  operation  rule  means 
that  an  addition  expression  is  of  type  Int  if  both  of  its  two  operands  are  of  type  Int.  In  this  type  system,  we 
can  have  typing  derivations  like  the  following: 


b  1  :  Int  h^Jjnt 
b  1  +  2  :  Int 

Note  that  there  are  no  ill-typed  expressions  in  this  type  system. 


2.2  Adding  Functions  to  the  Language 

The  type  system  we  have  just  defined  is  for  such  a  simple  language  that  it  has  little  practical  use.  In  this 
section  we  make  the  language  more  interesting  by  extending  the  simple  language  of  integer  arithmetic  with 
functions.  Like  in  most  functional  languages,  we  adopt  the  use  the  A-calculus  to  express  functions.  So  we 
extend  the  expression  syntax  with  the  A-calculus  expression  constructs:  expression  variables,  A-abstractions 
and  function  applications;  we  also  extend  the  type  syntax  with  an  function  arrow  construct.  The  expression 
syntax  and  type  syntax  of  the  new  language  is  defined  by  context  free  grammar  as  follows: 
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expression  syntax  : 

E 

1 

IntegerE 

LambdaE 

LambdaE 

X 

..  K, 

%  Ki 

type  syntax  : 

I 

1 

IntegerT 

LambdaT 

LambdaT  = 

T->T 

In  these  definitions,  E  and  T  still  stand  for  expression  syntax  and  type  syntax  respectively.  E  includes  two 
kinds  of  expression  syntaxes,  IntegerE  and  LambdaE,  while  T  includes  two  kinds  of  type  syntaxes  IntegerT 
and  LambdaT.  Both  of  them  are  extended  with  A-calculus  constructs  on  the  base  of  integer  arithmetic 
constructs.  Then  we  show  the  inference  rules  for  type  checking  the  A-calculus  expression  syntax  constructs. 


I  H  x  :  1 


_ x ,  - - -  (A  —  abstraction) 

r  h  (Ax  :  T'.E)  :T'-+T 


rh£i:r'~>r  r  I-  E2  :  v  (function  application ) 

T  h  Ej  E2  :  T 

Note  that  a  type  assignment  context  Y,  which  maps  expression  variable  names  to  types,  is  introduced  into 
the  type  checking  rules  by  the  extension  of  A-calculus.  The  var  rule  means  that  an  expression  variable  is  of 
the  type  that  is  assigned  to  it  by  the  type  assignment  context;  the  A  -  abstraction  rule  means  that  Ax  :  T  .E 
is  of  type  T  -¥  T  in  the  context  r  if  E  is  typed  T  in  the  context  Yx,  x  :  T',  where  Yx,  x  :  V  specifies  a  type 
assignment  context  that  maps  all  the  expression  variables  to  the  same  types  as  Y  but  the  variable  x  to  the 
type  T the  function  application  rule  means  that  the  function  application  expression  (El  E 2)  is  of  type 
in  the  context  Y,  if  El  is  of  type  V  ->  T  in  the  same  context  T,  and  E 2  is  typed  V  in  the  same  context  Y. 

The  extension  of  functions  to  the  original  type  system  is  static  semantics  preserving,  in  the  sense  that  well- 
typed  expressions  in  the  original  type  system  remain  well-typed  and  ill-typed  expressions  in  the  original  type 
systems  remain  ill- typed.  Because  there  are  new  expression  syntax  constructs  in  the  extended  type  system, 
there  are  more  well-typed  expressions,  such  as  the  following: 


x  :  Int  h  x  :  Int  x  :  Int  H  1  :  Int 
x  :  Int  b  x  +  1  :  Int 
h  (Ax  :  Int.x  +  1)  :  Int  — >  Int 

h  (Ax  :  Int.x  +  1)  2  :  Int 


h  2  :  Int 
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Also,  there  are  more  ill-typed  expressions  in  the  new  type  system,  such  as  i  +  l(unbounded  variable), 
(2  1) (invalid  application)  and  Xx  :  Int  -»  Int.x  +  1  (type  mismatch). 


2.3  Adding  Polymorphism  to  the  Language 

So  far  we  have  two  type  features  in  our  type  system:  integer  arithmetic  and  functions.  In  this  section  we 
make  the  use  of  functions  more  powerful  by  allowing  polymorphism.  The  expression  syntax  is  extended  with 
new  constructs  for  polymorphism:  type  abstractions  and  type  applications;  the  type  syntax  is  also  extended 
with  polymorphism  constructs:  type  variables  and  polymorphic  type  schemes.  The  syntax  of  the  this  new 
language  is  given  by  context  free  grammars  as  follows: 


expression  syntax  : 

E  =  IntegerE 

|  LambdaE 
j  PolyE 
PolyE  =  A  a.E 
|  E  T 

type  syntax  : 

T  =  IntegerT 

LambdaT 
|  PolyT 
PolyT  =  a 

1  Va.T 

Now  there  are  three  kinds  of  syntaxes  in  both  E  and  T.  E  is  extended  with  PolyE  on  the  base  of  Integer  E 
and  LambclaE ,  while  T  is  extended  with  PolyT  on  the  base  of  IntegerT  and  LambdaT.  The  inference  rules 
for  type  checking  the  expression  syntax  constructs  for  polymorphism  are  shown  as  follows: 


rb  E:T  a<£FV(T) 
r  b  A a.£  :  Va.T 


(type  abstraction ) 


rb£:  Va.T 
r  b  E  V  :  [T’/a)T 


(type  application ) 


The  type  abstraction  rule  means  that  A a.E  is  of  type  Va.T  in  context  P  if  E  is  of  type  T  in  the  same  context 
T  and  the  type  variable  name  a  does  not  appear  freely  in  T;  the  type  application  rule  means  that  E  V  is  of 
type  [T'/a]T  in  context  T  if  E  is  of  type  Va.T  in  the  same  context  T,  where  [T'/a]T  is  the  type  obtained  by 
substituting  all  the  free  occurrence  of  the  type  variable  a  in  the  type  T  with  the  type  T' .  Like  the  extension 
of  A-calculus,  the  extension  of  polymorphism  is  also  static  semantic  preserving.  There  are  more  well-typed 
expressions  related  with  the  polymorphism  expression  syntax  constructs,  such  as  the  following: 


x  :  a  l~  x  :  a 
h  Xx  :  a.x  :  a  — >  a 
b  Aa.Xx  :  a.x  :  Ma.a  — »•  a 

Also  there  are  more  ill-typed  expressions,  such  as  Aa.Xx  :  a..? +  1  (type  mismatch),  3  7n£(bad  type  application) 
and  (Aa.Ax  :  a.x)  1  (instantiation  needed). 
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2.4  A  Modular  Pattern 


In  the  previous  three  sections,  we  define  a  type  system  consisting  of  three  type  features:  integer  arithmetic, 
A-calculus  and  polymorphism.  This  type  system  is  developed  in  a  compositional  style  by  three  steps.  In  the 
first  step,  we  define  the  syntax  for  a  simple  language  of  integer  arithmetic,  and  describe  its  static  semantics 
by  a  set  of  type  checking  rules  for  its  expressions;  then  in  the  second  step,  we  extend  the  type  system  by 
adding  A-calculus  syntax  constructs,  together  with  the  static  semantics  for  the  newly  added  expressions; 
finally  in  the  last  step,  we  extend  the  type  system  again  with  new  syntax  constructs  for  polymorphism,  and 
the  corresponding  static  semantics  for  the  new  expressions.  If  we  consider  the  first  step  as  extending  an 
empty  type  system  (a  type  system  with  no  syntax  at  all  and  thus  no  static  semantics)  with  integer  arithmetic 
syntax  and  static  semantics,  then  all  of  the  three  step  can  be  seen  as  some  kind  of  extension  to  an  existing 
type  system  with  new  syntax  structures  and  new  static  semantics.  We  name  these  extension  parts  building 
blocks”,  for  they  are  the  components  that  build  up  the  type  system.  By  composing  a  building  block  with 
an  existing  type  system,  we  will  get  a  new  type  system  extended  with  the  type  feature  associated  with  the 
building  block.  In  this  sense,  building  blocks  can  also  be  seen  as  “type  system  transformers  that  transform 
a  type  system  to  another.  With  the  notion  of  building  blocks,  we  can  review  the  construction  of  the  type 
system  we  defined  from  another  perspective:  starting  from  an  empty  type  system,  we  put  in  three  building 
blocks  one  by  one  for  the  type  features  of  integer  arithmetic,  A-calculus  and  polymorphism  respectively.  The 
idea  can  be  captured  using  the  following  equation: 


my_ts  =  mkTS  (integerBlock  .  lambdaBlock  .  polyBlock) 


where  my.ts  stands  for  the  type  system  we  built;  11 . "  stands  for  some  composition  mechanism  between 
building  blocks;  mkTS  is  a  function  that  transforms  the  composition  of  building  blocks  to  a  type  system.  Later 
in  Section  4,  we  will  give  the  detailed  implementation  of  "  ."  and  mkTS. 

This  modular  approach  makes  the  construction  of  type  systems  very  flexible.  For  example,  if  we  observe  that 
the  type  features  of  A-calculus  and  polymorphism  can  be  combined  together  to  form  System  F[l],  in  which 
integer  type  and  values  can  be  encoded,  we  may  decide  not  to  have  the  type  feature  of  integer  arithmetic  in 
our  type  system.  This  can  be  done  by  simply  taking  away  the  building  block  for  integer  arithmetic  from  the 
construction  of  the  type  system: 


my_ts  =  mkTS  (lambdaBlock  .  polyBlock) 


For  another  example,  if  we  only  need  a  language  that  has  the  feature  of  integer  arithmetic,  logical  opeiations 
and  functions,  we  can  design  a  new  building  block  “boolBlock”  for  logical  operations,  and  compose  it  with 
the  building  blocks  for  integer  arithmetic  and  A-calculus  to  form  the  type  system  we  need: 


my_ts  =  mkTS  (integerBlock  .  boolBlock  .  lambdaBlock) 


2.5  Summary 

From  the  discussion  we  have  made,  we  understand  that  a  big  and  complex  type  system  with  many  type 
features  can  be  built  by  composing  some  independent  and  reusable  building  blocks,  each  of  which  implements 
a  particular  type  feature.  Different  type  systems  can  be  built  from  different  set  of  building  blocks  with 
different  composition  orders.  This  makes  it  easier  to  build  type  systems  for  DSLs.  We  can  design  a  large  set 
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of  building  blocks  in  advance,  which  cover  the  type  features  that  might  be  needed.  When  we  need  to  build  a 
type  system,  we  just  select  and  compose  the  building  blocks  that  implement  its  type  featuies.  In  case  we  need 
a  novel  type  feature  that  is  not  implemented  by  any  available  building  block,  we  can  design  a  new  building 
block  for  it  and  then  make  use  of  it.  The  cost  of  designing  a  new  building  block  might  be  high.  However, 
because  the  building  blocks  are  reusable,  we  do  it  once  and  for  all. 


3  Build  Syntax  for  Modular  Type  Systems 

In  the  following  two  sections,  we  will  give  an  implementation  in  Haskell  for  the  modular  type  system  introduced 
in  the  previous  section.  As  stated,  a  type  system  is  a  combination  of  syntax  and  static  semantics.  So  as  to 
build  a  modular  type  system,  we  need  to  build  both  its  syntax  and  static  semantics  in  a  modular  fashion. 
These  two  problems  will  be  addressed  separately.  In  this  section  we  show  how  to  deal  with  syntax.  Syntax 
includes  expression  syntax  and  type  syntax.  We  will  show  how  to  construct  the  type  syntax  in  a  evolutionary 
manner,  and  then  give  the  construction  of  the  expression  syntax  directly  using  the  same  idea. 

3.1  Type  Syntax 

We  want  to  build  the  syntax  for  a  type  system  that  consists  of  three  type  features:  integer  arithmetic, 
A-calculus  and  polymorphism.  A  monolithic  representation  of  type  syntax  is  shown  as  follows: 

datatype  =  INT  ”  constant  type  INT 

|  Fun  Type  Type  —  function  arrow 

1  TVar  String  ”  type  variable 

|  Forall  String  Type  —  polymorphic  type 

If  we  want  to  represent  the  type  syntax  in  a  modular  fashion,  we  need  to  break  this  monolithic  definition 
into  three  pieces  for  the  three  type  features  respectively.  First  we  show  a  method  of  decomposing  the  syntax 
directly: 

type  Type  =  IntType  <+>  LCType  <+>  FType 
data  IntType  =  INT 
data  LCType  =  Fun  Type  Type 
data  FType  =  TVar  String 

1  Forall  String  Type 

data  a  <+>  b=La|Rb  —a  sum  type  constructor 

Here  we  literally  break  the  monolithic  definition  of  Type  into  three  pieces,  each  of  which  captures  the  type 
syntax  of  one  type  feature.  These  three  pieces  are  composed  with  a  <+>  operator  to  form  a  new  definition  of 
Type  that  is  essentially  equivalent  to  the  original  monolithic  one.  However,  there  is  a  problem  in  this  method: 
the  definitions  of  LCType  and  FType  are  mutually  recursive  with  the  definition  of  Type,  which  makes  them 
depend  on  each  other;  as  a  result,  it  is  hard  for  these  definitions  to  appear  independently  in  separate  modules. 

To  address  this  problem,  we  refine  our  decomposition  by  parameterization.  We  use  type  parameters  to 
abstract  away  the  dependence  of  LCType  and  FType  on  Type,  and  thus  we  reduce  the  coupling  between  these 
definitions. 


—  type  syntax  for  integer  arithmetic 
—  type  syntax  for  lambda  calculus 

—  type  syntax  for  polymorphism 


type  Type 

data  IntTypeGen  t  = 
data  LCTypeGen  t  = 
data  FTypeGen  t  = 


(IntTypeGen  Type)  <+> 
I  NT 

Fun  t  t 
TVar  String 
Forall  String  t 


(LCTypeGen  Type)  <+> 

—  open  type  syntax 

—  open  type  syntax 

—  open  type  syntax 


(FTypeGen  Type) 
for  integer  arithmetic 
for  lambda  calculus 
for  polymorphism 


We  will  call  these  parameterized  constructors  ,  such  as  IntTypeGen,  LCTypeGen  and  FTypeGen,  open  syntax  , 
in  the  sense  that  they  do  not  prematurely  determine  what  the  final  type  syntax  should  be,  but  leave  the  type 
parameter  as  an  interface  for  extension.  In  this  new  method  of  decomposition,  the  definition  of  the  three  open 

syntax  pieces  do  not  involve  recursion  at  all,  so  they  can  exist  independently;  the  definition  of  Type  becomes 

self  recursive,  which  simplifies  the  definition  structure.  However,  note  that  there  are  some  redundancies  in 
the  definition  of  Type,  in  which  we  repeat  the  use  of  Type  three  times  for  recursion. 

To  eliminate  the  redundancy,  we  lift  the  <+>  operator  to  do  the  sum  on  two  open  syntaxes: 

data  (newTypeGen  <+>  oldTypeGen)  t 
=  NewType  (newTypeGen  t) 

|  OldType  (oldTypeGen  t) 

Now  we  can  use  the  new  <+>  to  compose  the  open  syntax  pieces. 

type  FinalTypeGen  =  IntTypeGen  <+>  LCTypeGen  <+>  FTypeGen 
type  Type  =  FinalTypeGen  Type 

By  this  means,  we  eliminate  the  redundancy  problem.  Furthermore,  we  observe  that  Type  is  actually  the  fix 
point  of  the  constructor  FinalTypeGen.  We  capture  this  point  and  refine  the  way  of  defining  Type  with  a  fix 
point  operator. 


data  Tfix  t  =  MkType  (t  (Tfix  t)) 
type  Type  =  Tfix  FinalTypeGen 

The  fix  point  operator  Tfix  shuts  down  the  extension  interface  of  an  open  syntax  and  turns  it  into  a  closed 
syntax”.  With  this  approach  of  defining  type  syntax,  we  gain  the  ability  of  writing  functions  on  type  syntax 
structures  with  more  flexible  types.  For  example,  consider  a  function  to  test  the  syntactic  equality  of  two 
pieces  of  type  syntax.  Without  the  Tfix  operator,  we  can  only  give  the  following  form  of  type  to  it, 


Type  ->  Type  ->  Bool . 

Because  Type  is  defined  in  an  ad-hoc  way,  this  function  type  only  works  for  one  kind  of  type  syntax  composed 
by  a  particular  set  of  open  syntax  pieces.  However,  with  the  help  of  Tfix  operator,  we  can  have  a  more 

generic  type: 


Tfix  t  ->  Tfix  t  ->  Bool. 
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Note  that  the  type  variable  t  is  polymorphic  in  this  type,  so  it  can  be  instantiated  to  any  composition  of 
open  syntaxes.  As  a  result,  the  type  of  every  function  that  test  syntactic  equality  on  type  syntax  can  be  an 
instance  of  this  type. 


3.2  Expression  Syntax 

We  will  use  the  same  technique  used  to  deal  with  type  syntax  to  define  expression  syntax.  First,  we  define 
three  open  syntax  constructors. 


data  IntExprGen  e  t 
data  LCExprGen  e  t 


data  FExprGen  e  t 


IntLit  Int 
Add  e  e 
Var  String 
Lam  String  t  e 
App  e  e 
TLam  String  e 
TApp  e  t 


—  integer  literals 

—  addition  expression 

—  expression  variable 

—  lambda  abstraction 

—  function  application 

—  explicit  type  abstraction 

—  type  application 


A  difference  between  the  expression  open  syntax  and  the  type  open  syntax  is  that  it  is  parameterized  with 
two  type  variables,  one  for  expression  syntax,  the  other  for  type  syntax.  This  is  because  the  construction  of 
some  expression  syntax  requires  the  use  of  type  syntax.  For  example,  the  expression  syntax  of  A-abstraction 
uses  type  syntax  for  the  function  parameter  type. 

The  definition  of  the  <+>  operator  of  the  expression  syntax  is  just  like  that  of  the  type  syntax. 


data  (newExprGen  <+>  oldExprGen)  e  t 
=  NewExpr  (newExprGen  e  t) 

|  OldExpr  (oldExprGen  e  t) 

The  fix  point  operator  of  expression  syntax  is  Ef  ix,  whose  definition  involves  the  Tf  ix  operator.  For  a  similar 
reason,  Ef  ix  also  takes  two  parameters,  like  the  expression  open  syntax. 


data  Efix  e  t  =  MkExpr  (e  (Efix  e  t)  (Tfix  t)) 


The  datatype  Expr  is  defined  as  follows: 

type  FinalExprgen  =  IntExprGen  <+>  LCExprGen  <+>  FExprGen 
type  Expr  =  Efix  FinalExprGen  FinalTypeGen 


4  Build  Static  Semantics  for  Modular  Type  System 

Having  shown  how  to  build  syntax,  we  will  now  show  how  to  build  the  static  semantics  for  the  modular  type 
system . 
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4.1  Type  Checking  Function 


As  stated,  we  consider  the  static  — 

zzzzzzzz  -  - *  - — “t  b^“;X 

expressions  to  exist  so  we  n«d  to  ■  —  a  -text  ,»  ™  f\ype  parent  daring  the 
process  of  type  checking.  For  another  exan  p  ,  checking  contexts  into  account 

&ES&2&££Sg£ssB " ~  ‘  - 


Expr  ->  CM  Type, 


where  CM  denotes  some  context  monad. 


4.2  Open  System,  Closed  System  and  Building  Blocks 

In  order  to  illustrate  our  way  of  building  modular  static  semantics, 

open  system,  closed  system  and  building  block.  An  open  any  real  type 

that  has  an  standard  interface  foi  extension.  ecaus  as  argument  and  returns  another 

checking  facilities.  A  building  block  is  a  J y  “  feature.  It  does  the  extension  using  the  original 

open  system  extended  with  static  seman  ic  svstem  that  exposes  the  same  standard 

open  system’s  standard  extension  interface,  and  geneia  e  svstem  transformers.  So  far,  we  get  open 

extension  interface.  Building  blocks  can  also  e  tiougi  o  a  geries  of  building  blocks  to  an  open 

systems  and  building  blocks  “  op“  ^w^ver^  known,’ open  systems  don’t  supply  type  checking  facilities, 

rrj 

If  can  not  be  extended  any  further  but  has  the  ability 

to  do  type  checking  work. 


4.2.1  Data  Representation  of  Closed  Systems 

We  define  a  Haskell  datatype  for  closed  systems: 


data  Closed  exprGen  typeGen  conGen 

=  Closed  {topTypeChk  : :  (Ef ix  exprGen  typeGen) 

conGen  (Tfix  typeGen) 
—  some  auxiliary  functions 


-> 

(Tfix  typeGen) 


> 


The  datatype  Closed  is  nsec ^  t0 »"  expression  open 
an"  t>  LCExpr);  the  parameter  typeGen  is  a  constructor  that  specifles  a  type  open 
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syntax,  such  as  (IntType  <+>  LCType);  the  envGen  parameter  specifies  a  parameterized  monad  that  captures 
the  type  checking  context.  It  is  parameterized  by  a  type  closed  syntax  because  some  type  checking  contexts 
may  be  related  with  type  structure  of  the  type  system.  For  example,  the  type  assignment  environment 
context  for  A-calculus  can  be  considered  as  a  finite  function  from  a  set  of  variable  names  to  types.  The 
Closed  datatype  is  a  record  type  that  contains  a  topTypeChk  function  field.  A  closed  system  offers  the 
type  checking  facility  by  its  topTypeChk  field.  The  topTypeChk  function  takes  a  expression  closed  syntax  as 
argument  and  returns  its  type  in  a  closed  syntax  form  which  is  encapsulated  in  the  type  checking  context 
monad. 

Besides  the  topTypeChk  function,  we  also  have  some  auxiliary  fields,  which  will  be  introduced  later  as  they 
are  needed. 


4.2.2  Data  Representation  of  Open  Systems 
Also,  we  define  a  Haskell  datatype  for  open  systems: 


data  Open  exprGen  typeGen  conGen 

=  Open  {typeChk  ::  forall  e  t  c.ErrorMonad  (c  (Tfix  t))  => 

Closed  e  t  c  -> 

SubType  (typeGen  (Tfix  t))  (Tfix  t)  -> 
LiftM  (conGen  (Tfix  t))  (c  (Tfix  t))  -> 
exprGen  (Efix  e  t)  (Tfix  t)  ->  c  (Tfix  t) 
...  —  some  auxiliary  functions 


} 


(Tfix  t) , 


The  datatype  Open  is  also  parameterized  with  variables,  which  have  the  same  name  and  meaning  as  those 
of  the  datatype  Closed.  The  Open  datatype  is  also  a  record  type.  Its  contains  a  typeChk  function  field.  A 
value  whose  type  is  of  the  form  Open  exprGen  typeGen  envGen  is  an  open  system  that  exposes  an  extension 
interface  by  its  typeChk  function  field.  The  function  typeChk  is  explicitly  defined  to  be  polymorphic.  Its 
type  is  universally  quantified  by  three  type  variables  e,  t  and  a.  This  kind  of  definition  is  known  as  rank- 
2  polymorphism [4].  The  type  variables  e  and  t  specify  the  top-level  open  syntaxes  that  are  ready  to  be 
converted  to  closed  syntaxes  by  fix  point  operators  Efix  and  Tfix.  The  type  variable  c  specifies  the  top-level 
parameterized  context  monad  which  will  be  use  as  the  type  checking  context  in  the  final  closed  system.  These 
three  type  variables  will  be  instantiated  when  an  open  system  is  transformed  to  a  closed  system. 

An  open  system  offers  the  standard  extension  interface  by  its  typeChk  function  field.  The  function  typeChk 
has  a  type  class  predicate  and  three  arguments.  It  returns  a  value  whose  type  is  also  a  function  type.  In  the 
following,  we  will  explain  the  meaning  of  the  types  of  the  arguments  and  the  return  value,  and  show  their 
use. 

The  type  class  predicate  restricts  the  context  monad  to  have  the  ability  of  raising  an  error  during  the  process  of 
type  checking.  Note  that  c  (Tfix  t))  specifies  the  top  level  type  checking  context  monad.  The  constructor 
class  ErrorMonad  is  defined  as  follows: 


class  Monad  m  =>  ErrorMonad  m  where 
f ailE  : :  m  a 
liftE  : :  Maybe  a  ->  m  a 
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The  overloading  function  failE  is  to  be  used  to  raise  an  error;  the  overloading  function  liftE  is  to  be  used 
to  lift  a  Maybe  monad  value  to  the  an  ErrorMonad  value. 

The  parameter  of  the  type  Closed  etc  represents  a  top-level  closed  system  that  will  be  built  on  the  base 
of  the  current  level  of  open  system.  It  is  passed  back  from  the  top  level  down  to  the  current  level  because  we 
need  the  top  level  type  checking  facility  to  construct  the  current  level  typeChk  function.  The  use  of  rank-2 
polymorphism  gives  us  the  ability  of  using  a  closed  system  without  prematurely  determine  the  actual  value 
of  its  three  type  parameters  e,  t  and  c.  These  values  will  be  determined  when  the  open  system  has  develope 
full-fledged  and  is  transformed  to  a  closed  system. 

The  parameter  of  the  type  SubType  (typ.Gen  (Tfix  t»  (Tfix  t)  specifies  a  explicit  sabtyping  relation¬ 
ship  between  the  current  level  of  type  open  syntax  and  the  top  level  type  closed  syntax.  It  i 
because  we  do  transformation  between  current  level  and  top  level  type  syntax  in  order  to  construct  the 
typeChk  function.  The  SubType  relation  is  defined  as  follows: 


data  SubType  a  b 
=  SubType  {inj 
proj 


a  ->  b, 

:  b  ->  Maybe  a} 


The  function  inj  injects  a  type  open  syntax  of  the  current  level  into  a  top  level  type  closed  syntax;  the 
function  proj  projects  a  top-level  type  closed  syntax  to  a  type  open  syntax  of  the  cuirent  leve  . 

The  parameter  of  type  LiftM  (envGen  (Tfix  t))  (a  (Tfix  t))  serves  as  a  lift  operator  thatliftsanoper- 
ation  defined  in  the  current  level  context  monad  into  the  top  level  context  monad.  It  is  specially  defined  for 
lifting  the  operations  of  environment  monads,  because  most  type  checking  is  done  with  in  environme 
monads.  The  definition  of  the  datatype  LiftM  is  as  follows: 


data  LiftM  m  n 

=  LiftM  {liftRdEnv 
liftlnEnv 


> 


forall  a.m  a  ->  n  a, 
forall  a  b. (a  ->  m  b  ->  m  b)  -> 
(a  ->  n  b  ->  n  b) 


Normally,  there  are  two  non-standard  operations^]  in  an  environment  monad,  one  of  which  >s  to  r^d  °u 
current  environment,  the  other  is  to  enforce  a  computation  to  be  done  in  a  new  environment.  The  func  on 
liftRdEnv  lifts  the  operation  of  reading  the  current  environment;  the  function  liftlnEnv  lifts  the  opera 
of  doing  a  computation  in  a  new  environment. 

The  return  value  of  the  typeChk  function  is  of  the  type  exprGen  (Efix  e  t)  (Tfix  t)  ->  a  (Tfix  t) 
(Tfix  t)  This  is  a  function  type  which  is  much  like  the  type  of  the  topTypeChk  function  defined  in  the 
datatype)  Closed  The  return  value  can  be  considered  as  the  current  level  type  checking  function.  It  takes 
a  vaTof  the  -irent  level  open  expression  syntax  as  argument  and  returns  its  type  in  a  close  syntax  form 
which  is  encapsulated  in  the  top  level  context  monad. 

Like  closed  systems,  the  datatype  Open  also  has  some  corresponding  auxiliary  fields  which  will  be  introduced 
as  needed. 
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4.2.3  Building  Blocks,  top  and  bot 

Building  blocks  are  open  system  transformers,  whose  type  will  be  of  the  form: 

Open  e  t  c  ->  Open  e’  t ’  c’. 

Because  building  blocks  are  functions,  we  can  simply  use  function  composition  to  compose  two  building  blocks 
to  obtain  a  larger  composite  building  block.  For  example,  if  we  have  a  building  block  of  type: 

Open  e  t  c  ->  Open  e’  t’  c’, 

and  another  building  block  of  type: 

Open  e’  t’  c’  ->  e’’  t ’ ’  c’’, 

then  we  can  compose  them  using  function  composition  to  obtain  a  larger  building  block  of  type: 

Open  e  t  c  ->  Open  e’ ’  t ’ ’  c’’. 

Till  now  we  know  that  the  composition  between  building  blocks  is  right  function  composition. 

As  indicated  previously,  we  need  to  have  a  special  function  top  whose  type  will  be  of  the  following  form: 

Open  e  t  c  ->  Closed  etc. 

The  function  top  actually  serves  as  a  fix  point  operator,  just  like  Efix  and  Tfix.  It  transforms  an  open 
system  to  a  closed  one  by  computing  its  fix  point.  In  our  framework  of  modular  type  systems,  every  closed 
system  is  a  fixed  point  of  some  open  system. 

So  far,  we  have  only  considered  system  transformers,  besides  which  we  also  need  an  initial  base  open  system  to 
start  with  in  order  to  finally  construct  a  closed  system.  This  base  open  system  is  called  bot  in  our  framework 
of  modular  type  system. 

With  all  the  notions  defined  in  this  section,  the  mechanism  to  build  the  static  semantics  for  the  modular  type 
system  is  clear.  Given  a  set  of  building  blocks,  bl,  b2,  b3,  we  first  use  function  composition  to  compose  them 
to  obtain  a  big  composite  building  block;  then  we  apply  this  big  building  block  to  the  base  open  system  bot 
to  get  an  open  system;  finally  we  apply  top  to  the  open  system  to  get  its  fix  point  as  a  closed  system.  The 
final  closed  system  includes  the  static  semantics  for  type  features  associated  with  the  building  blocks  bl,  b2 
and  b3.  This  idea  can  be  shown  by  the  following  expression: 

my_ts  =  top  ((bl  .  b2  .  b3)  bot). 


The  value  my_ts  stands  for  a  modular  type  system.  The  (".")  operator  used  here  is  just  the  built-in  Haskell 
function  composition  operator.  Now  we  can  define  the  mkTS  function  as  follows: 


mkTS  x  =  top  (x  bot) 


Then  we  can  rewrite  the  definition  of  my_ts  as: 


my_ts  =  mkTS  (bl  .  b2  .  b3) 


4.3  Implementation  of  the  Building  Blocks 

Now  we  give  the  implementation  of  the  three  building  blocks  associated  with  the  type  features  of  integer 
arithmetic,  A-calculus  and  polymorphism  respectively. 


4.3.1  A  Building  Block  for  Integer  Arithmetic 

We  will  start  by  showing  the  building  block  for  integer  arithmetic. 

integerBlock  : :  Open  e  t  c  ->  Open  (IntExprGen  <+>  c)  (IntTypeGen  <+>  t)  c 
integerBlock  1 

=  let  typeChk_  =  ...  —  Definition  of  type  checking  function, 

in  Open  {typeChk  =  typeChk.} 


The  integerBlock  extends  an  open  system  with  new  syntax  structures  of  integer  arithmetic.  The  parameter¬ 
ized  context  monad  c  is  not  extended,  because  this  building  block  does  not  add  any  new  expression  variable 
syntax  into  the  expression  syntax  structure.  The  definition  of  the  typeChk  function  can  be  divided  into  two 
parts,  one  for  type  checking  the  new  expression  syntax  add  by  integerBlock,  the  other  for  type  checking 
the  old  expression  syntax  inherited  from  the  original  open  syntax.  Here  We  show  a  sketch  of  the  definition 
of  the  type  checking  function.  This  will  be  divided  into  two  parts,  one  for  type  checking  the  new  expression 
syntaxes  added  by  the  current  building  block,  the  other  for  type  checking  the  old  expression  syntaxes  in  the 
original  open  system. 


typeChk.  top  s  _  (NewExpr  nt) 

=  let  te  =  (topTypeEq  top) 
topTC  =  (topTypeChk  top) 


—  Closed  type  syntax  equality  comparison. 

—  Top-level  type  checking. 


in  case  nt  ot 
IntLit  _ 

->  return  ( ( ( in j  s).NewType)  INT) 


—  Type  check  integer  literals. 


Add  tl  t2 

->  do  typl  <-  topTC 
typ2  <-  topTC 
if  (typl  fte‘ 
(typ2  ‘tef 
then  return 
else  failE 


—  Type  check 
tl  —  Type  check 

t2  —  Type  check 

( ( ( in j  s).NewType)  INT))  && 

( ( ( in j  s).NewType)  INT)) 

( ( ( in j  s) .NewType)  INT) 


addition  expression, 
first  operand, 
second  operand. 

—  If  both  of  the  two  operands 

—  are  typed  INT,  then  return 

—  INT,  otherwise  raise  an 

—  error. 
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In  type  checking  the  new  expressions,  we  implement  the  two  typing  rules  for  integer  arithmetic  expressions, 
one  for  type  checking  integer  constants,  the  other  for  type  checking  addition  expressions.  In  this  definition, 
top  specifies  the  top  level  closed  system,  and  s  specifies  the  encoding  of  the  subtyping  relationship  between 
the  current  level  open  type  syntax  and  the  top  level  closed  type  syntax.  Two  local  functions,  te  and  topTC  are 
defined  to  help  the  implementation.  The  function  topTC  represents  the  topTypeChk  field  of  the  argument  top, 
which  specifies  the  top  level  closed  type  checking  function.  The  function  te  represents  the  topTypeEq  function 
field  of  the  argument  top,  which  tests  the  syntactic  equality  of  two  pieces  of  top  level  closed  type  syntax.  Note 
that  there  is  actually  an  auxiliary  function  field  typeEq  in  the  open  systems  and  a  corresponding  function 
field  topTypeEq  in  the  closed  systems.  This  auxiliary  function  is  designed  to  test  the  syntactic  equality  of 
the  type  syntaxes.  Its  definition  is  omitted  in  this  paper  because  of  the  little  relevance  to  the  essential  idea 
and  the  straightforward  implementation.  The  phrase  (inj  sj.NewType  injects  the  current  level  open  type 
syntax  (INT  here)  to  the  top  level  closed  type  syntax. 


typeChk.  top  s  If  (OldExpr  ot) 

=  let  subtype 

=  let  inj_  =  (inj  s).01dType 


proj_  x 

=  do  xl  <-  (proj  s)  x 
case  xl  of 

OldType  t  ->  return  t 
->  failE 

in  SubType  {inj  =  inj_, 

proj  =  proj_> 


—  Inject  lower  level  open  type 

—  syntax  to  top  level  closed  type 

—  syntax. 

—  Project  top  level  closed  type 

—  syntax  to  lower  level  open  type 

—  syntax . 


—  Subtype  relation  between 

—  lower  level  and  top  level. 


in  (typeChk  1)  top  subtype  If  ot 


—  Call  the  lower  level  typeChk. 


In  type  checking  the  old  expressions,  we  make  use  of  the  function  integerBlock’s  argument  1,  which  specifies 
the  original  open  system.  Essentially,  we  use  its  typeChk  function  field  to  type  check  the  old  expression  syntax 
inherited  from  the  original  open  system.  To  call  the  lower  level  typeChk  function,  we  just  pass  the  argument 
top  directly.  However,  we  need  to  pass  newly  constructed  subtyping  encoding  argument  and  lifting  encoding 
argument  to  fit  the  type  of  the  lower  level  typeChk  function.  Here  the  new  subtyping  encoding  is  defined 
on  the  base  of  the  current  level  subtyping  encoding,  while  the  lifting  encoding  stays  unchanged  because  this 
building  block  does  not  extend  the  parameterized  context  monad  at  all. 

From  the  definitions  shown  in  this  section,  we  can  summarize  a  clear  strategy  to  design  the  typeChk  function 
field  of  open  systems:  implement  the  typing  rules  for  type  checking  the  new  expression  syntaxes  added  by 
the  current  building  block,  and  use  the  lower  level  typeChk  function  field  of  the  original  open  system  to  deal 
with  the  old  expression  syntaxes  inherited  from  the  original  open  system. 


4.3.2  A  Building  Block  for  A-Calculus 

We  continue  to  show  a  more  complex  building  block,  which  is  for  A-calculus. 
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data  LCCon  t  =  LCCon  [(String,  t)]  —  New  environment  type:  each  pair 

—  associates  a  type  with  a  string 

—  that  represents  a  variable  name. 

data  EnvT  r  m  t  a  =  EnvT  (r  t  ->  m  t  a)  —  Environment  monad  transformer. 
applyEnvT  (EnvT  f)  =  f 

lambdaBlock  : :  (MonadGen  c)  => 

Open  e  t  c  ->  Open  (LCExprGen  <+>  e)  (LCTypeGen  <+>  t)  (EnvT  LCCon  c) 

lambdaBlock  1 

=  let  typeChk_  =  ... 

in  Open  {typeChk  =  typeChk„} 

The  lambdaBlock  extends  an  open  system  with  new  syntax  structures  of  A-calculus.  Unlike  the  integerBlock, 
it  also  extends  the  parameterized  context  monad  with  a  layer  of  environment  monad  using  the  monad  trans¬ 
former  EnvT.  This  is  because  a  type  assignment  environment  is  needed  to  type  checking  the  expressions  in 
A-calculus.  A  datatype  LCCon  specifies  the  type  assignment  environment  added  by  lambdaBlock.  It  is  defined 
as  a  list  of  pairs  of  strings  and  type  closed  structures,  where  the  strings  specify  expression  variable  names. 
The  type  class  predicate  MonadGen  c  restricts  the  type  parameter  c  of  the  original  open  syntax  to  be  a  pa¬ 
rameterized  monad.  The  detailed  definition  of  the  EnvT  datatype  and  the  MonadGen  constructor  class  will 
attached  in  the  appendix. 

The  design  of  the  typeChk  function  for  lambdaBlock  follows  the  basic  strategy  stated  when  constructing 
integerBlock.  We  divide  the  function  into  two  parts.  In  type  checking  the  new  expressions  syntaxes  added 
by  the  current  building  block,  we  implement  the  typing  rules  for  each  of  them;  in  type  checking  the  old 
expression  syntaxes  inherited  from  the  original  open  system,  we  make  use  of  the  lower  level  typeChk  function. 
A  sketch  of  the  definition  of  the  typeChk  function  is  shown  as  follows. 

typeChk.  top  s  If  (NewExpr  nt)  —  If  is  the  lift  operator  that  lifts  the  two 

—  nonstandard  operations  of  current  level  context 

—  monad  up  to  the  top  level 

=  let  te  =  (topTypeEq  top) 

topTC  =  (topTypeChk  top) 

rdEnv  =  EnvT  (\(LCEnv  r)  ->  return  r)  —  Current  level  rdEnv . 

inEnv  r  m  =  EnvT  (\ri  ->  applyEnvT  m  r)  —  Current  level  inEnv . 

lookup  =  ... 

match  =  ... 

update  =  ... 

in  case  nt  of 
Var  x 

->  do  env  <-  (liftRdEnv  If)  rdEnv  —  Get  current  environment. 

lookup  x  env  —  Look  up  a  expression  variable’s  type. 

App  el  e2 

->  do  f  <-  topTC  tl  —  Type  check  the  function, 

x  <-  topTC  t2  —  Type  check  the  argument, 

r  <-  liftE  (match  f  x)  —  Match  the  argument  type 

—  against  the  function  type. 

return  r 
Lam  v  t  e 
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->  do  env  <-  (liftRdEnv  If)  rdEnv  —  Get  current  environment, 

r  <-  ( (liftlnEnv  If)  inEnv)  —  Type  check  the  function 

(LCEnv  (update  (v,  b)  env))  —  body  in  an  updated  environment. 
(topTC  t) 

return  ( ( ( in j  s).NewType)  (Fun  b  r)) 


In  type  checking  the  new  expressions,  the  meaning  of  the  arguments  top  and  s  is  as  same  as  in  the  definition 
of  integerBlock.  The  argument  If  specifies  the  encoding  of  a  lift  operator  which  is  used  to  lift  the  non¬ 
standard  operations  of  the  current  level  context  monad  into  the  top  level  context  monad.  The  meaning  of 
the  local  functions  te  and  topTypeChk  in  this  definition  is  as  same  as  in  the  definition  of  integerBlock.  The 
local  functions  rdEnv  and  inEnv  are  related  with  the  type  assignment  context  of  the  type  checking.  They 
are  actually  the  two  non-standard  operations  of  the  current  level  environment  monad.  The  function  rdEnv 
is  used  to  read  out  the  environment  context  at  the  point  it  is  called;  while  the  function  inEnv  is  used  to 
force  a  type  checking  to  be  done  in  a  particular  given  type  assignment  context.  The  function  rdEnv  is  used 
in  type  checking  the  expression  variables  and  A-abstractions.  When  it  is  used,  it  has  to  be  lifted  using  the 
phrase  (liftRdEnv  If)  to  fit  the  top  level  type  checking  context  monad.  The  function  inEnv  is  used  in 
type  checking  A-abstractions.  When  it  is  used,  it  has  to  be  lifted  using  the  phrase  (liftlnEvn  If)  to  fit 
the  top  level  type  checking  context  monad.  There  are  also  three  other  local  functions:  lookup,  match  and 
update.  The  function  lookup  is  used  to  lookup  the  type  of  a  given  expression  variable  in  the  type  assignment 
environment.  The  function  match  is  used  to  match  a  given  type  against  the  argument  part  of  a  function  arrow 
type,  and  returns  the  result  part  of  the  same  function  arrow  type.  The  function  update  is  used  to  update  the 
type  assignment  environment  with  new  bindings  of  expression  variables  and  types.  The  implementations  of 
these  three  functions  are  omitted  here  because  they  are  quite  straightforward. 

typeChk_  top  s  If  (OldExpr  ot) 

=  let  subtype  =  ... 
newlf 

=  let  liftRdEnv.  re  =  (liftRdEnv  If)  (EnvT  (\_  ->  re)) 
liftlnEnv.  ine 

=  (liftlnEnv  If)  (\r  m  ->  (EnvT  (\rl  ->  ine  r  (applyEnvT  m  rl)))) 
in  LiftM  {liftRdEnv  =  liftRdEnv., 
liftlnEnv  =  liftlnEnv.} 
in  (typeChk  1)  top  subtype  newlf  ot 

The  part  of  type  checking  the  old  expressions  of  the  current  building  block  is  similar  as  that  of  integerBlock, 
except  that  besides  making  a  new  encoding  of  the  subtyping  relationship,  we  also  need  to  make  a  new  encoding 
of  the  lift  operation  to  be  passed  as  an  argument  to  the  lower  level  typeChk  function.  This  is  because  the 
current  building  block  extends  the  context  monad  with  a  layer  of  environment  monad  by  applying  a  monad 
transformer  to  it,  so  the  operations  in  the  lower  layer  monads  need  to  be  lifted  through  this  monad  transformer. 
The  local  value  newlf  specifies  the  newly  constructed  encoding  of  the  lift  operation.  To  lift  the  lower  level 
operations  to  the  top  level,  we  first  lift  them  through  the  monad  transformer  EnvT  to  the  current  level,  and 
then  use  the  current  level  lift  operator  to  lift  them  up  to  the  top  level. 


4.3.3  A  Building  Block  for  Polymorphism 

Finally,  we  show  an  interesting  building  block,  which  is  for  polymorphism.  Before  giving  the  definition,  we 
state  some  important  problems  that  do  not  show  up  in  the  former  two  building  blocks  but  appear  here.  The 


polymorphism  building  block  will  introduce  two  pieces  of  new  expression  syntax:  explicit  type  abstraction 
and  explicit  type  application.  In  the  typical  rule  of  type  checking  type  abstraction  expressions,  we  need  to 
judge  whether  a  type  variable  name  appears  freely  in  the  type  checking  context;  in  the  typical  rule  of  type 
checking  type  application  expressions,  we  need  to  do  substitutions  on  type  structures  in  order  to  instantiate 
a  polymorphic  type.  So,  the  building  block  for  polymorphism  must  have  functionality  to  accomplish  these 
two  tasks.  We  add  an  auxiliary  function  mapT  to  the  datatype  of  open  systems  to  achieve  this. 

data  Open  exprGen  typeGen  envGen 
=  Open  { . . . 

mapT  ::  forall  m  t  v. Monad  m  => 

(t  ->  m  v)  -> 

(typeGen  t  ->  m  (typeGen  v)), 

> 

The  function  mapT  is  explicitly  defined  as  polymorphic  a  function.  This  is  the  use  of  rank-2  polymorphism 
again.  In  its  types,  the  universally  quantified  type  variable  t  specifies  the  top-level  type  syntax  structure;  the 
type  variable  m  specifies  an  arbitrary  monad,  as  constrained  by  the  type  class  predicate  Monad  m;  the  type 
variable  v  specifies  the  return  type  of  the  function  to  be  mapped  onto  the  type  structure.  One  thing  to  note  is 
that,  the  mapT  function  is  not  as  usual  map  functions  for  algebraic  datatypes.  Normal  map  functions  should 
have  the  type  of  the  following  form: 

(a  ->  b)  ->  (C  a  ->  C  b) , 

where  C  is  the  datatype  constructor.  The  mapT  function  has  a  type  of  the  following  form. 

(a  ->  M  b)  ->  (C  a  ->  M  (C  b)) 

where  C  is  still  the  datatype  constructor,  while  M  is  a  monad.  So  mapT  actually  maps  a  Kleisli  function[6]  onto 
an  algebraic  datatype.  It  does  the  mapping  with  a  side  effect  encoded  in  a  monad.  If  we  take  the  monad  as 
the  identity  monad,  then  the  mapT  function  will  be  degraded  to  a  normal  map  function.  The  side  effect  allows 
us  to  define  many  useful  functions  using  mapT.  As  will  be  shown  later,  both  the  free  type  variable  checking 
function  and  the  type  variable  substitution  function  can  be  defined  by  using  the  facility  offered  here. 

Now  we  can  begin  to  show  the  definition  of  the  building  block  for  polymorphism. 

polyBlock  : :  Open  e  t  a  ->  Open  (FExprGen  <+>  e)  (FTypeGen  <+>  t)  a 
polyBlock  1 

=  let  typeChk_  =  ... 

in  Open  {typeChk  =  typeChk_> 

The  polyBlock  extends  an  open  system  with  new  syntax  structures  of  polymorphism.  It  does  not  extend 
the  parameterized  context  monad,  because  there  is  no  new  expression  variables  syntax  introduced  by  this 
building  block. 

The  definition  of  the  typeChk  function  for  this  building  block  also  follows  the  basic  strategy.  We  will  only 
show  a  sketch  of  type  checking  the  new  expressions.  The  type  checking  of  the  old  expressions  is  as  same  as 
that  of integerBlock. 
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typeChk_  top  s  _  (NewExpr  nt) 

=  let  st  =  .  .  . 
ftEnv  =  ... 
in  case  nt  of 

TApp  e  t  ->  . . .  (st)  . . . 
TLam  t  e  ->  ...  (ftEnv)  . . . 


—  type  substitution 

—  free  type  variable  checking 

—  type  check  type  application 

—  type  check  type  abstraction 


Note  that  two  functions,  st  and  ftEnv,  are  used  to  do  type  substitution  and  free  variable  checking  respectively. 
In  the  implementation  of  the  typing  rule  of  type  application  expressions,  the  function  st  is  used  to  instantiate 
polymorphic  types;  in  the  implementation  of  the  typing  rule  of  type  abstraction,  the  function  ftEnv  is  used 
to  compute  the  type  variables  that  appear  freely  in  the  environment  context.  These  two  functions  are  both 
implemented  using  the  auxiliary  function  mapT. 


st  (v,  t)  typ 

=  case  (proj  s)  typ  of 

Just  (NewType  (TVar  x)) 

->  if  x  ==  v 

then  return  t 
else  return  typ 
Just  (NewType  (Forall  x  tt)) 

->  if  x  ==  v 

then  return  typ 

else  do  y  ->  st  (v,  t)  tt 

return  ( ( ( inj  s). NewType)  (Forall  x  y)) 

->  do  x  <-  (topMapT  top)  (st  (v,  t))  typ 
return  (MkType  x) 

In  this  code  segment,  (proj  s)  and  (inj  s)  are  the  projection  and  injection  functions  encoded  in  the 
argument  of  the  typeChk  function  that  specifies  the  subtyping  relationship  between  the  current  level  type 
structure  and  the  top-level  type  structure.  The  topMapT  function  is  the  counterpart  of  mapT  in  a  closed 
system.  It  can  be  seen  as  the  fix  point  of  the  mapT  function  of  an  open  system.  We  use  the  topMapT 
function  to  recursively  map  the  st  function  down  to  the  whole  structure  of  a  type  syntax  in  order  to  do 
a  type  substitution  on  it.  Here  the  mapT  function  does  not  have  any  side  effects.  Note  that  there  are  no 
non-standard  operations  of  the  monad  used  in  the  definition  of  st.  When  put  into  use,  the  polymorphic 
monad  in  the  type  of  mapT  will  be  instantiated  to  an  identity  monad. 


ftTyp  typ 

=  case  (proj  s)  typ  of 

Just  (NewType  (TVar  v)) 

->  do  1  ->  gets 

puts  (1  ‘setU‘  [v]) 

Just  (NewType  (Forall  v  t)) 

->  do  ftTyp  t 

1  ->  gets 

puts  (1  ‘ setDif ‘  [v]) 

_  ->  do  (topMapT  top)  ftTyp  typ 
return  () 
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ftEnv  a  =  . . .  ftType  . . . 


The  essence  of  ftEnv  is  the  function  ftType  defined  in  this  code  segment.  It  collects  all  the  type  variables  that 
appear  freely  in  a  type  syntax  structure.  In  defining  ftType,  the  side  effects  of  the  mapT  operator  becomes 
important.  During  the  process  of  traversing  a  type  structure,  we  need  to  “remember”  the  free  type  variables 
that  have  been  found.  So  the  polymorphic  monad  is  instantiated  to  a  state  monad.  The  gets  function  and 
puts  function  are  the  two  non-standard  operations  of  the  state  monad,  where  gets  used  to  read  out  the 
current  state  of  the  computation  and  puts  is  used  to  update  the  state.  Note  that  the  return  value  of  ftType 
function  becomes  trivial  (a  void  value  is  always  returned).  The  result  of  this  function  focus  on  the  side  effect 

is  produces. 


4.4  Build  a  Closed  System 

So  far  we  have  finished  the  definitions  of  the  three  building  blocks.  In  this  section  we  will  show  how  these 
building  block  can  be  composed  to  form  a  closed  system  with  real  checking  facility.  As  mentioned,  we  need 
to  have  a  special  function  top  that  transforms  an  open  system  to  a  closed  one,  and  an  initial  open  system 
bot  as  the  base  open  system  for  the  modular  type  system.  Here  we  show  the  sketch  of  top  and  bot. 

top  ::  ErrorMonad  (c  (Tfix  t))  =>  Open  e  t  c  ->  Closed  etc 
top  1 

=  let  typeChk.  (MkExpr  t) 

=  (typeChk  1)  (top  1)  . . .  t  —  compute  the  fix  point  of  typeChk  function 

in  Closed  {topTypeChk  =  typeChk_> 


data  BotExprGen  e  t  =  Unit  “  a  single  expression 

data  BotTypeGen  t  =  Void  a  single  type 

data  BotEnvGen  t  a  =  Ok  a  I  Error  —  context  monad  is  set  to  be  an  error  monad 

bot  : :  Open  BotExprGen  BotTypeGen  BotEnvGen 
bot  =  Open  {typeChk  =  . . .} 

The  function  top  takes  an  open  system  as  argument  and  returns  a  closed  system.  The  type  class  predi¬ 
cate  ErrorMonad  (c  (Tfix  t))  restricts  the  context  monad  to  have  the  ability  of  raising  an  error.  The 
topTypeChk  function  field  computes  the  fix  point  of  the  original  open  system’s  typeChk  function.  So  the 
function  top  shuts  off  the  extension  interface  of  an  open  system  and  generate  a  close  system  that  supplies 
the  type  checking  facility  by  the  topTypeChk  function  field. 

The  value  bot  is  an  open  system.  It  only  contains  one  single  expression  and  one  single  type,  which  is  like  the 
unit  expression  and  unit  type  in  Haskell.  In  this  initial  open  system,  we  set  the  base  of  the  context  monad 
to  be  an  error  monad,  so  any  open  system  built  on  the  base  of  bot  will  be  able  to  raise  an  error  in  its  type 

checking  context. 

Now  we  can  finally  finish  the  construction  of  the  static  semantics  of  our  modular  type  system  that  contains 
the  type  feature  of  integer  arithmetic,  A-calcultts  and  polymorphism: 


my_ts  =  mkTS  (integerBlock  .  lambdaBlock.  polyBlock) 
mkTS  x  =  top  (x  bot) 
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4.5  Some  Running  Results 


All  the  codes  can  be  found  at  the  URL: 

http : / /www . cse . ogi . edu/"chiyan/mainpage/research_pro j ect/ codes 


These  codes  can  be  run  under  Hugs98  interpreter  by  loading  the  file  test.hs.  In  test.hs,  we  define  some 
values  that  represent  type  systems: 

intSys  =  mkTypeSys  (integerBlock) 

lambdaSys  =  mkTypeSys  (integerBlock  .  lambdaBlock) 

polySys  =  mkTypeSys  (integerBlock  .lambdaBlock  .  polyBlock) 

Some  running  results  are  shown  as  follows: 


—  (tc  intSys)  "0" 

"Int" 

—  (tc  intSys)  "1  +  (2  +  3)" 

"Int" 

—  (tc  lambdaSys)  "/x:Int  ->  x  +  1" 

"Int  ->  Int" 

—  (tc  lambdaSys)  "(/x:Int  ->  x  +  1)  2" 

"Int" 

—  (tc  lambdaSys)  "(2  1)" 

"bad  type!" 

—  (tc  polySys)  "#a  ->  /x:a  ->  x" 
forall  a. (a  ->  a) 

—  (tc  polySys)  "((#a  ->  /x:a  ->  x)  [Int])  1" 
Int 


—  (tc  polySys)  "#a  ->  /x: a  ->  x  +  1" 

"bad  type!" 

Here  tc  is  the  composition  of  the  topTypeChk  function  field  of  the  closed  system  and  some  parsing  func¬ 
tion  that  parses  the  character  inputs  to  the  abstract  datatype  of  an  expression  closed  syntax.  The  symbol 
"/"  stands  for  the  expression  variable  abstraction  symbol  A.  The  symbol  "#"  stands  for  the  type  variable 
abstraction  symbol  A.  All  the  running  results  are  as  expected. 
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5  Related  Work 


There  are  some  other  works  related  with  the  topic  in  this  paper,  such  as  Levin  and  Pierce’s  work  of  Tinker 
Type[7],  and  research  on  pure  type  systemsfl].  However,  they  solve  different  problems  from  what  we  are 
dealing  with  here.  Tinker  Type  focuses  on  modular  specifications  of  type  systems,  while  we  focus  on  mod¬ 
ular  static  semantics  of  type  systems.  In  this  sense,  our  work  is  more  similar  to  Liang,  Hudak  and  Jones 
work  of  modular  interpreters[8],  except  that  their  work  is  to  explore  the  modularity  of  dynamic  semantic  of 
programming  languages.  The  work  of  pure  type  systems  defines  a  generic  framework  for  type  systems,  allows 
the  construction  of  type  systems  by  switching  parameters.  It  is  different  from  our  work  because  it  does  not 
build  type  systems  in  a  compositional  style,  and  does  not  divide  the  static  semantics  of  type  systems  into 
independent  and  reusable  building  blocks  as  we  do  in  this  paper. 

The  essential  idea  of  our  method  to  decompose  type  systems  is  similar  to  Duponcheel[9]  and  Sheng  Liang’s 
work  to  decompose  interpreters.  However,  we  propose  a  totally  different  way  of  implementation  in  this  papei. 
They  make  extensive  use  of  constructor  classes,  while  make  use  of  rank-2  polymorphism. 

The  strength  of  their  approach  is  that  all  the  building  blocks  are  define  as  an  instance  of  a  constructor  class, 
so  they  can  be  implicitly  composed  by  the  type  system  and  overloading  mechanism  of  the  language  they  use 
to  do  the  implementation.  However,  they  have  to  explicitly  compose  the  open  syntax  pieces  for  expression 
structures  and  type  structures.  Also,  they  hide  those  subtyping  relationships  and  lift  operators  for  monad 
transformers  using  constructor  classes.  This  makes  their  building  blocks  look  elegant,  without  having  those 
complex  detail  appearing  explicitly.  The  price  they  pay  is  that  all  their  building  blocks  depend  on  each  other, 
so  they  must  be  organized  in  such  a  way  that  they  are  visible  to  anyone  else.  This  prevent  the  building  blocks 
from  being  separately  compiled. 

The  strength  of  our  approach  is  that  we  don’t  have  to  explicitly  compose  the  open  syntax  pieces,  because 
those  types  are  strongly  polymorphic  so  that  they  are  implicitly  composed  when  we  do  the  composition  of 
building  blocks.  However,  we  have  to  define  explicit  mechanism  to  compose  the  building  blocks.  Also,  we 
don’t  rely  on  the  implicit  passing  mechanism  of  constructor  classes  and  all  our  subtyping  relationships  and  lift 
operators  are  explicitly  passed  as  function  parameters,  so  our  building  blocks  exist  independently  and  can  be 
separately  complied.  The  price  we  pay  is  that  we  lose  the  elegant  presentation  of  building  blocks,  because  the 
subtyping  relationship  and  lift  operators  are  explicit  passed  as  function  parameters,  and  all  of  their  details 
need  to  be  redefined  in  every  building  block  repeatedly. 

So  it  is  about  a  trade-off  here,  llsing  their  approach,  it  would  be  easier  to  add  in  dynamic  features,  because 
dynamic  features  can  be  encoded  into  monads  and  implemented  using  constructor  classes.  However,  it  will 
be  inconvenient  for  them  to  add  in  a  building  block  because  that  requires  their  overall  implementation  to  be 
modified  and  recompiled.  Using  our  approach,  it  would  be  easier  to  add  in  a  building  block,  because  all  our 
building  block  exist  independently  and  the  newly  added  building  block  does  not  affect  others  at  all.  However, 
we  meet  trouble  if  we  want  to  extends  the  system  with  some  dynamic  features.  That  would  require  radical 
changes  to  our  overall  framework  because  we  need  to  add  more  parameters  to  the  some  functions 


6  Conclusion  and  Future  Work 

In  this  paper  we  show  a  way  to  construct  a  modular  type  system  by  defining  and  composing  reusable  and 
independent  building  blocks.  Although  we  only  show  three  building  blocks  in  this  presentation,  we  actually 
make  seven  building  blocks  for  the  following  type  system  features:  integer  arithmetic,  logical  expression, 
variable  definition,  first  order  functions,  A-calculus,  Hindley-Milner  features,  and  polymorphism.  We  make 
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a  novel  use  of  rank-2  polymorphism,  which  plays  a  important  role  in  the  framework  of  our  modular  type 
system;  and  we  define  a  new  kind  of  map  operator  that  maps  a  Kleisli  function  onto  an  algebraic  datatype, 
which  makes  the  map  operator  more  powerful. 

This  paper  is  only  a  starting  attempt  to  construct  modular  type  systems,  and  there  are  lots  of  opportunities 
for  future  work. 

The  framework  needs  to  be  refined.  We  are  not  satisfied  with  the  means  we  currently  use  to  deal  with  the 
subtype  relation  and  the  lift  operator.  We  want  to  remove  those  explicit  parameters  from  the  interface  of  the 
type  checking  function  to  have  a  more  elegant  solution.  This  might  involve  the  use  of  constructor  classes[10]. 

The  framework  needs  to  be  extended  to  accommodate  new  features.  For  example,  if  we  want  to  include 
the  feature  of  Aw[l]  into  our  modular  type  system  framework,  and  thus  a  kind  system,  we  must  extend  the 
framework  to  accommodate  kinds  besides  expressions  and  types. 

Also,  we  need  to  develop  more  building  blocks  in  order  to  study  the  interaction  between  type  system  features, 
such  as  how  qualified  type[ll]  interferes  with  Hindley  Milner  polymorphism[12]. 

Another  possible  direction  of  this  work  is  to  develop  higher  order  abstractions  for  modular  type  systems. 
We  observe  that  there  are  similarities  between  some  of  the  building  blocks  we  have  developed.  We  want  to 
capture  the  similarities  and  design  generic  building  blocks. 


7  Appendix 

7.1  The  Definition  of  Constructor  Class  MonadGen 

The  constructor  class  MonadGen  defines  a  class  of  parameterized  monads.  If  m  is  a  parameterized  monad,  then 
for  any  type  t,  (m  t)  is  a  monad. 


class  MonadGen  m  where 
returnG  : :  a  ->  m  t  a 

bindG  : :  m  t  a  ->  (a  ->  m  t  b)  ->  m  t  b 

instance  MonadGen  m  =>  Monad  (m  t)  where 
return  =  returnG 
(>>=)  =  bindG 
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7.2  The  Definition  of  Datatype  EnvT 


The  datatype  EnvT  is  a  parameterized  monad  transformer.  It  transforms  a  parameterized  monad  to  another 
by  adding  a  layer  of  environment  monad  feature. 

data  EnvT  r  m  t  a  =  EnvT  (r  t  ->  in  t  a) 
apply EnvT  (EnvT  f)  a  =  f  a 

instance  MonadGen  in  =>  MonadGen  (EnvT  r  m)  where 
returnG  x  =  EnvT  (\r  ->  returnG  x) 
m  ‘bindG*  k 

=  EnvT  (\r  ->  applyEnvT  m  r  ‘bindG‘  (\x  -> 
applyEnvT  (k  x)  r)) 

Any  ErrorMonad  can  be  lifted  through  the  EnvT  transformer.  If  (m  t)  is  an  ErrorMonad,  so  is  (EnvT  r  m 
t). 

instance  (ErrorMonad  (m  t) ,  Monad  (EnvT  r  m  t))  =>  ErrorMonad  (EnvT  r  m  t)  where 
failE  =  EnvT  (\r  ->  failE) 
liftE  m  =  EnvT  (\r  ->  liftE  m) 
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Abstract 

Functional  Reactive  Programming  (FRP)  is  a  declarative  program¬ 
ming  model  for  constructing  interactive  applications  based  on  a 
continuous  model  of  time.  FRP  programs  are  described  in  terms  of 
behaviors  (continuous,  time-varying,  reactive  values),  and  events 
(conditions  that  occur  at  discrete  points  in  time). 

This  paper  presents  FrappS,  an  implementation  of  FRP  in  the 
Java  progamming  language.  The  primary  contribution  of  Frappe 
is  its  integration  of  the  FRP  event/behavior  model  with  the  Java 
Beans  event/property  model.  At  the  interface  level,  any  Java  Beans 
component  may  be  used  as  a  source  or  sink  for  the  FRP  event  and 
behavior  combinators.  This  provides  a  mechanism  for  extending 
Frapp6  with  new  kinds  of  I/O  connections  and  allows  FRP  to  be 
used  as  a  high-level  declarative  model  for  composing  applications 
from  Java  Beans  components.  At  the  implementation  level,  the  Java 
Beans  event  model  is  used  internally  by  Frappe  to  propagate  FRP 
events  and  changes  to  FRP  behaviors.  This  allows  Frapp6  applica¬ 
tions  to  be  packaged  as  Java  Beans  components  for  use  in  other  ap¬ 
plications,  and  yields  an  implementation  of  FRP  well-suited  to  the 
requirements  of  event-driven  applications  (such  as  graphical  user 
interfaces). 

1  Introduction 

Recent  work  in  in  the  functional  programming  community  has  pro¬ 
posed  Functional  Reactive  Programming  (FRP)  as  a  declarative 
programming  model  for  constructing  interactive  applications.  FRP 
programs  are  described  in  terms  of  behaviors  (continuous,  time- 
varying,  reactive  values),  and  events  (conditions  that  occur  at  dis¬ 
crete  points  in  time).  The  FRP  style  was  first  proposed  in  Fran  [5], 
a  domain-specific  language  for  computer  animation  embedded  in 
Haskell.  The  motivation  for  developing  Fran  was  to  enable  the  pro¬ 
grammer  to  focus  on  modelling  of  the  problem  domain  rather  than 
on  presentation  details  required  to  produce  sequential  frames  of  an 
animation.  Since  then,  FRP  has  been  adapted  for  numerous  other 
application  domains,  including  robotics  [14,  13],  vision  [16]  and 
graphical  user  interfaces  [17]. 

All  previous  implementations  of  FRP  have  been  embedded  in 
the  Haskell  programming  language  [15].  As  discussed  in  [8], 
Haskell’s  lazy  evaluation,  rich  type  system,  and  higher-order  func¬ 
tions  make  it  an  excellent  basis  for  development  of  new  domain- 
specific  languages  and  new  programming  paradigms  such  as  FRP. 
Haskell  has  served  as  a  basis  for  more  than  a  half  dozen  implemen¬ 
tations  of  FRP  [4,  9,  17]. 

■"This  material  is  based  upon  work  supported  under  a  National  Science  Foundation 
Graduate  Research  Fellowship.  Any  opinions,  findings,  conclusions  or  recommenda¬ 
tions  expressed  in  this  publication  are  those  of  the  author  and  do  not  necessarily  reflect 
the  views  of  the  National  Science  Foundation. 


In  the  Java  community,  recent  work  has  produced  the  Java 
Beans  component  model  [2].  The  Java  Beans  component  model 
prescribes  a  set  of  programming  conventions  for  writing  re-usable 
“components”  for  use  in  an  Integrated  Development  Environment 
(IDE)  or  other,  similar  tool  (such  as  a  web  page  authoring  tool). 
A  programmer  writes  a  Java  Beans  component  by  defining  a  Java 
class  that  specifies  a  set  of  events  (“interesting”  conditions  which 
result  in  notifying  other  objects  of  their  occurence)  and  properties 
(named  mutable  attributes  of  the  component  that  may  be  read  or 
written  with  appropriate  methods).  A  visual  builder  tool  uses  Java’s 
introspection  facilities  [  1 1  ]  to  discover  the  events  and  properties  ex¬ 
ported  by  the  component  class.  Many  of  the  classes  in  the  standard 
Java  class  libraries  (such  as  those  of  AWT  and  Swing)  are  defined 
as  Java  Beans  components. 

The  FRP  and  Java  Beans  programming  models  have  very  dif¬ 
ferent  goals  and  appear,  at  first  glance,  to  be  completely  unrelated. 
The  goal  of  FRP  is  to  enable  the  programmer  to  write  concise 
descriptions  of  interactive  applications  in  a  declarative  modelling 
style,  whereas  the  goal  of  Java  Beans  is  to  provide  a  component 
framework  for  visual  builder  tools.  However,  the  two  models  also 
have  some  alluring  similarities:  both  have  a  notion  of  events ,  and 
both  have  a  notion  of  values  that  change  over  time  ( behaviors  in 
FRP,  properties  in  Java  Beans).  Our  primary  motivation  for  devel¬ 
oping  Frapp6  was  to  to  explore  the  relationship  between  the  two 
models. 

As  a  secondary  motivation,  we  developed  Frapp£  to  explore  us¬ 
ing  FRP  for  composing  interactive  applications  from  Java  Beans 
components.  All  of  the  commerically  available  IDEs  for  Java  al¬ 
low  the  programmer  to  compose  user  interface  layouts  in  a  declar¬ 
ative,  visual,  direct  manipulation  style,  but  require  the  programmer 
to  write  (imperative)  Java  code  to  make  this  interface  actually  do 
anything.  This  approach  raises  a  number  of  difficult  issues  for  de¬ 
velopers  and  users  of  IDEs,  such  as  requiring  every  component  of 
the  U I  to  be  exposed  as  a  public  field,  ensuring  that  user-written 
Java  code  isn’t  lost  when  the  UI  layout  code  is  regenerated,  and 
managing  all  of  the  Java  code  attached  to  the  UI  to  ensure  that  every 
event  handler  leaves  the  program  in  a  consistent  state.  We  believe 
that  many  of  these  problems  could  be  redressed  by  specifying  event 
handlers  using  some  high-level  declarative  programming  model  in¬ 
stead  of  writing  Java  code  directly.  Providing  an  implementation 
of  FRP  in  Java  provides  just  such  a  model  for  Java  application  pro¬ 
grammers  and  IDE  developers. 

This  paper  presents  Frappe,  an  implementation  of  FRP  in  Java. 
Our  implementation  is  based  on  a  correspondence  between  the  FRP 
and  Java  Beans  programming  models,  and  our  implementation  in¬ 
tegrates  the  two  models  very  closely.  There  are  two  aspects  to  this 
integration:  First,  any  Java  Beans  component  may  be  used  as  a 
source  or  sink  for  the  FRP  event  and  behavior  combinators.  Sec¬ 
ond,  the  Java  Beans  event  model  is  used  internally  by  Frapp6  for 
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propagation  of  FRP  events  and  changes  to  FRP  behaviors.  Allow¬ 
ing  any  Java  Beans  component  to  be  used  as  a  source  or  sink  for  the 
FRP  event  and  behavior  combinators  allows  the  Java  programmer 
to  use  FRP  as  a  high-level  declarative  model  for  composing  interac¬ 
tive  applications  from  Java  Beans  components,  and  allows  FrappS 
to  be  extended  with  new  kinds  of  I/O  connections  without  modi¬ 
fying  the  Frapp6  implementation.  Using  the  the  Java  Beans  event 
model  internally  allows  Java  Beans  components  connected  by  FRP 
combinators  to  be  packaged  as  larger  Java  Beans  components  for 
use  by  other  Beans-aware  Java  tools,  and  yields  a  “push”  model  for 
propagation  of  behavior  and  event  values  that  is  well-suited  to  the 
requirements  of  graphical  user  interfaces. 

The  remainder  of  this  paper  is  organized  as  follows.  Section  2 
gives  a  brief  review  of  the  FRP  and  Java  Beans  models.  Sec¬ 
tion  3  describes  an  existing  implementation  of  FRP  in  Haskell,  and 
states  some  observations  about  the  properties  of  this  implementa¬ 
tion.  Section  4  presents  our  implementation  of  Frapp6,  using  the 
observations  presented  in  section  3  to  justify  the  derivation,  and 
also  describes  how  Java  Beans  components  can  be  used  directly  as 
sources  or  sinks  for  the  FRP  combinators.  Section  5  summarizes 
the  status  of  the  implementation.  Section  6  discusses  some  lim¬ 
itations  of  our  implementation.  Section  7  describes  related  work. 
Section  8  summarizes  our  contributions,  and  briefly  discusses  some 
open  questions  and  plans  for  future  work. 

2  Preliminaries 

2.1  Functional  Reactive  Programming 

Functional  Reactive  Programming  (FRP)  is  a  high-level  declara¬ 
tive  programming  model  for  constructing  interactive  applications. 
In  this  section,  we  give  a  very  brief  introduction  to  the  aspects  of 
FRP  needed  to  understand  the  rest  of  the  paper;  see  [5,  9]  for  more 
details.  For  concision,  FRP  examples  presented  in  this  section  are 
given  in  Haskell  [15],  and,  to  keep  the  discussion  grounded  in  con¬ 
crete  examples,  many  examples  are  taken  from  the  problem  domain 
of  computer  animation. 

The  principal  idea  that  distinguishes  FRP  from  most  other  pro¬ 
gramming  models  is  that  it  presents  a  continuous  model  of  time 
to  the  application  programmer.  Of  course,  actual  implementations 
of  FRP  on  real  computers  will  only  approximate  the  continuous 
model  by  some  form  of  discrete  sampling,  but  this  implementation 
complexity  is  (mostly)  hidden  from  the  application  programmer. 

There  are  two  key  polymorphic  data  types  in  FRP:  the  Behav¬ 
ior  and  the  Event.  Conceptually,  a  Behavior  is  a  time-varying 
continuous  value.  One  can  think  of  type  Behavior  a  as  having 
the  Haskell  definition: 

type  Behavior  a  =  Time  ->  a 

That  is,  a  value  of  type  Behavior  a  is  a  function  from  Time  to 
a.  Given  this  definition,  we  can  think  of  sampling  a  behavior  as 
simply  applying  the  behavior  to  some  sample  time.  The  simplest 
examples  of  behaviors  are  constant  behaviors:  those  that  ignore 
their  time  argument  and  evaluate  to  some  constant  value.  For  ex¬ 
ample,  constB  red  has  type  Behavior  Color.  It  evaluates  to 
red  regardless  of  the  sample  time.  An  example  of  a  time-varying 
behavior  (taken  from  a  binding  of  FRP  for  computer  animation  [5]) 
is  mouse  (of  type  Behavior  Point).  When  sampled,  mouse 
yields  a  representation  of  the  mouse  position  at  the  given  sample 
time.  Sampling  the  mouse  at  different  times  may  yield  a  different 
Point  depending  on  whether  the  user  has  moved  the  mouse. 

Conceptually,  an  Event  is  some  condition  that  occurs  at  a  dis¬ 
crete  point  in  time.  In  Haskell,  we  write  the  type  Event  a  for  an 
event  source  capable  of  producing  a  sequnce  of  occurences ,  where 
each  occurence  carries  a  value  of  type  a.  For  example: 


lbp  : :  Event  ( ) 

key  : :  Event  Char 

declare  the  types  of  two  primitive  event  sources  defined  in  the  FRP 
binding  for  computer  animation.  The  first  event  source,  lbp, 
generates  an  event  occurence  every  time  the  left  mouse  button  is 
pressed.  Each  occurence  carries  a  value  of  type  ( )  (read  “unit”), 
meaning  that  there  is  no  data  carried  with  this  event  other  than  the 
fact  that  it  occured.  The  second  event  source,  key,  generates  an 
event  occurence  every  time  a  key  is  pressed  on  the  keyboard.  Each 
occurence  carries  a  value  of  type  char  representing  the  key  that 
was  pressed. 

An  implementation  of  FRP  provides  the  programmer  with  a  set 
of  primitive  behaviors  and  event  sources,  and  a  library  of  combi¬ 
nators  for  creating  new  behaviors  and  event  sources  from  existing 
ones.  For  example,  the  expression: 

lbp  -=>  red 

uses  the  -=>  combinator  (of  type  Event  a  ->  b  ->  Event  b) 
to  produce  an  event  source  of  type  Event  Color.  The  event  oc¬ 
curs  whenever  lbp  occurs  (i.e.  every  time  the  left  mouse  button  is 
pressed),  but  each  occurence  carries  the  value  red.  More  complex 
event  sources  and  behaviors  are  produced  by  nested  applications  of 
combinators.  For  example,  the  expression: 

(lbp  -=>  red  . | .  rbp  -=>  blue) 

uses  the  merge  operator  (  .  |  . )  to  produce  an  an  event  source  (of 
type  Event  Color)  that  occurs  whenever  the  left  or  right  mouse 
button  is  pressed.  When  the  left  button  is  pressed,  an  occurence  is 
generated  carrying  the  value  red;  when  the  right  button  is  pressed, 
an  occurence  is  generated  carrying  the  value  blue. 

The  FRP  model  defines  a  combinator,  switcher,  for  convert¬ 
ing  an  event  source  to  a  behavior.  The  type  of  switcher  is  given 
as: 

switcher  : :  Behavior  a  ->  Event  (Behavior  a)  - 

>  Behavior  a 

Informally,  swi  tcher  produces  a  behavior  that  initially  follows  its 
first  argument.  However,  every  time  an  event  occurs  on  the  event 
source  given  as  the  second  argument,  switcher  “switches”  to  fol¬ 
low  the  behavior  carried  in  that  event  occurence.  For  example: 

c  =  switcher  red  (lbp  -=>  red  . | .  rbp  -=>  blue) 

uses  switcher  to  define  c  as  a  behavior  with  type  Behavior 
Color1.  When  the  application  starts,  c  will  initially  be  red.  When 
the  left  mouse  button  is  pressed,  c  changes  to  red,  and  when  the 
right  mouse  button  is  pressed,  c  changes  to  blue. 

Complete  applications  are  written  in  FRP  by  defining  reactive 
behaviors.  Reactive  behaviors  are  behaviors  that  change  in  re¬ 
sponse  to  user  input,  such  as  the  definition  of  c  just  given.  A 
binding  of  FRP  for  a  particular  problem  domain  will  usually  define 
a  type  for  a  top-level  behavior  that  represents  the  output  of  the  ap¬ 
plication.  A  complete  application  is  defined  simply  by  using  the 
FRP  combinators  to  write  an  expression  for  a  behavior  of  this  type. 
For  example,  in  computer  animation,  the  output  of  an  application 
is  of  type  Behavior  Picture.  An  example,  then,  of  a  complete 
FRP  application  for  computer  animation  is: 

exampleApp  =  withColor  c  circle 

where  c  =  switcher  red  (lbp  -=>  red  . | . 

rbp  -=>  blue) 

1  Here  we  use  implicit  lifting  of  constants  to  Behaviors.  Strictly  speaking,  we  should 
have  written  constB  red  instead  of  just  red,  but  the  Haskell  implementations 
of  FRP  use  instance  declarations  to  perform  this  translation  automatically. 
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this  application  renders  a  circle  of  unit  size  in  an  output  window. 
The  circle  will  be  initially  red,  but  the  color  will  change  between 
red  and  blue  as  the  left  and  right  mouse  button  are  pressed. 

2.2  Java  Beans 

This  section  gives  a  brief  summary  of  the  Java  Beans  programming 
model.  For  a  more  complete  account,  the  reader  is  referred  to  the 
Java  Beans  Specification  [2]. 

2.2.1  What  is  a  Bean? 

The  Java  Beans  Specification  defines  a  Java  Bean  informally  as  “a 
reusable  software  component  that  can  be  manipulated  visually  in  a 
builder  tool”.2  For  example,  all  of  the  Swing  user  interface  compo¬ 
nents  (buttons,  sliders,  windows,  etc.)  are  Beans.  However,  Beans 
need  not  have  any  visual  appearance  at  run-time.  For  example,  a 
software  component  that  takes  a  ticker  symbol  as  input  and  peri¬ 
odically  delivers  stock  quotes  for  the  ticker  symbol  could  easily  be 
packaged  as  a  Bean. 

More  concretely,  then,  a  Bean  is  a  Java  class  that  conforms 
to  certain  programming  conventions  prescribed  by  the  Java  Beans 
specification.  These  conventions  specify  that  a  Bean  should  make 
its  functionality  available  to  clients  through: 

•  Properties- mutable  named  attributes  of  the  object  that  can  be 
read  or  written  by  calling  appropriate  accessor  methods. 

•  Events- A  named  set  of  “interesting”  things  that  may  happen 
to  the  Bean  instance.  Clients  may  register  to  be  notified  when 
an  event  occurs  by  implementing  a  listener  interface.  When 
the  event  occurs,  the  component  notifies  the  client  by  invok¬ 
ing  a  method  defined  in  the  listener  interface. 

•  Methods-Ordmary  Java  methods,  invoked  for  their  side- 
effects  on  the  Bean  instance  or  its  environment. 

The  Beans  model  does  not  require  a  separate  interface  defini¬ 
tion  language  for  specifying  the  interface  to  a  Java  Beans  compo¬ 
nent.  Instead,  the  Beans  model  prescribes  that  a  Java  Bean  can  be 
written  as  an  orindary  Java  class  in  the  Java  language,  and  can  be 
packaged  for  use  by  a  builder  tool  simply  by  compiling  the  source 
file  to  the  standard  Java  class  file  format.  The  “builder  tools”  use 
reflection  [1 1]  on  the  class  file  to  recover  information  about  the  fea¬ 
tures  exported  by  the  particular  Bean,  and  the  standard  Java  library 
provides  a  set  of  helper  classes  in  the  java. beans  package  for 
use  by  builder  tools.  These  helper  classes  perform  the  low-level  re¬ 
flection  operations  to  recover  information  about  events,  properties 
and  methods  supported  by  a  Bean. 

2.2.2  Properties 

Properties  are  mutable,  named  attributes  of  a  component.  For  ex¬ 
ample,  each  of  the  graphical  user  interface  components  in  the  Java 
Swing  library  defines  width  and  height  properties  that  represent  the 
bounding  box  of  the  component’s  visual  representation.  Conceptu¬ 
ally,  a  property  is  similar  to  a  field  of  an  object,  and  properties  are 
often  implemented  by  storing  the  property  value  in  a  field.  How¬ 
ever,  a  property  need  not  be  implemented  this  way;  a  component 
implementation  could  instead  compute  a  property’s  value  dynami¬ 
cally  when  the  property  is  read. 

Properties  are  accessed  by  means  of  accessor  methods ,  which 
are  used  to  read  and  write  values  of  the  property.  A  property  may 

2In  the  remainder  this  paper,  we  use  the  terms  “Java  Beans  component”  and  “Bean” 
interchangeably. 


be  readable  or  writable  (or  both),  which  determines  whether  the 
property  supports  get  or  set  accessor  methods.  The  Java  Beans 
specification  defines  programming  conventions  that  component  au¬ 
thors  must  follow  when  writing  accessor  methods.  The  convention 
for  get  accessor  methods  is: 

public  PropertyType  get  PropertyName  ()  ; 

and  the  convention  for  set  accessor  methods  is: 

pub  lie  void  set  PropertyName  { PropertyType  ar  g )  ; 

where  PropertyName  is  the  (appropriately  capitalized)  name  of  the 
property,  and  PropertyType  is  the  Java  type  of  the  property.  Con¬ 
tinuing  with  the  previous  example,  the  class  JComponent  of  Java 
Swing  defines  get  and  set  accessors  for  its  width  and  height  prop¬ 
erties  as: 

public  class  JComponent  { 

public  int  getWidthO; 
public  void  setWidth{int  arg) ; 

public  int  getHeight{); 
public  void  setHeight ( int  arg); 

} 

Invoking  getWidth  ( )  will  return  the  width  of  the  component  (in 
pixels);  Invoking  setwidth  ( )  will  set  the  component’s  width  (in 
pixels). 

2.2.3  Events 

Conceptually,  events  in  the  Java  Beans  component  model  are  a 
mechanism  used  by  a  source  component  to  notify  one  or  more  tar¬ 
get  listeners  of  some  state  change  in  the  source  object.  For  exam¬ 
ple,  a  Button  user  interface  object  might  define  an  action  event 
that  is  used  to  notify  listeners  when  the  button  has  been  pressed  by 
the  user.  The  Java  Beans  specification  requires  component  authors 
to  adhere  to  the  following  conventions: 

•  The  programmer  must  specify  an  event  class  to  encapsulate 
the  information  about  a  single  event  occurence.  This  event 
class  should  be  a  subclass  of  java  .beans  .Event  named 
event-name  Event,  where  event-name  is  a  logical  name  for  the 
event  chosen  by  the  component  author.3 

•  The  programmer  must  specify  a  listener  interface,  that  defines 
one  or  more  notification  methods.  A  listener  interface  has  the 
form: 

public  interface  event-nameListener  { 

public  void  notifyMethod  { event-name  Event  arg)  ; 

} 

where  event-name  is  as  before,  and  notifyMethod  is  a  method 
name  (chosen  by  the  component  author)  to  be  invoked  when 
the  event  occurs. 

•  The  programmer  must  add  a  pair  of  listener  registration  meth¬ 
ods  to  the  component  acting  as  the  event  source.  These  lis¬ 
tener  registration  methods  have  the  form: 

3Technically,  event-name  identifies  a  set  of  related  events  rather  than  a  single  event, 
but  this  distinction  is  not  important  here. 
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public  void 

addevent-namehistener  [event-name Listener  lis¬ 
tener)  ; 

public  void 

remo veevent-nameh  i  s  t  ener  ( event- 
nr/mfListener  listener) ; 

The  former  method  registers  a  listener  object  to  be  notified 
when  the  given  event  occurs;  the  latter  removes  a  previously 
registered  listener. 

An  example  of  a  Java  Beans  event  is  the  action  event  defined  by 
the  JButton  class  from  Java  Swing.  An  application  arranges  to 
be  notified  when  a  JButton  is  pressed  by  implementing  the  Ac- 
tionListener  interface  and  passing  a  reference  to  an  instance  of 
this  interface  to  the  addActionListener  ( )  method  of  JButton. 
The  implementation  of  JButton  records  the  listener  registration  in 
its  listener  list.  Later,  when  the  button  is  pressed  by  the  user,  the 
JButton  notifies  each  registered  listener  by  invoking  the  listener’s 
actionPerformedO  method,  passing  it  a  reference  to  an  Ac- 
tionEvent  with  information  about  the  event  occurence. 

2.2.4  Bound  Properties 

A  particularly  important  aspect  of  the  Java  Beans  specification  is  its 
provision  for  bound  properties.  A  component  author  may  specify 
that  a  property  is  a  bound  property,  meaning  that  interested  clients 
can  register  to  be  notified  whenever  the  property’s  value  changes. 
A  property’s  value  might  change  either  as  a  direct  result  of  the  ap¬ 
plication  program  invoking  a  set  accessor  method,  or  as  an  indirect 
result  of  some  user  action.  For  example,  a  text  entry  widget  might 
have  a  text  property  representing  the  text  entered  into  the  field  by 
the  user.  If  implemented  as  a  bound  property,  an  application  could 
register  to  be  notified  whenever  the  user  changed  the  contents  of 
the  text  entry  component. 

The  Java  Beans  specification  defines  a  Property- 
ChangeEvent  that  carries  information  about  a  change  to  a 
bound  property  (such  as  its  old  value  and  new  value),  and  a 
PropertyChangeListener  interface  that  must  be  implemented 
by  client  objects  that  wish  to  be  notified  of  changes.  As  we  will  see 
shortly,  bound  properties  play  a  critical  role  in  the  implementation 
of  FRP  Behaviors  in  Frapp6. 

3  Analysis  of  Stream-Based  FRP 

To  date,  there  have  been  numerous  implementations  of  FRP  in 
Haskell.  Some  of  the  design  alternatives  (and  their  associated  en¬ 
gineering  tradeoffs)  are  explored  in  [4].  An  efficient,  robust  imple¬ 
mentation  of  the  FRP  model  that  is  both  faithful  to  the  formal  se¬ 
mantics  and  does  not  suffer  from  space  leaks  or  other  performance 
problems  has  remained  an  elusive  goal,  and  we  do  not  expect  that 
this  situation  will  change  in  the  near  future. 

One  recent  implementation  of  FRP  that  has  received  particular 
scrutiny  is  the  so-called  stream-based  implementation,  described 
in  [9].4  A  related  paper  [18]  analyzes  this  implementation  formally, 
showing  that,  with  one  caveat3,  as  the  sample  time  approaches  0, 
the  implementation  is  faithful  to  the  formal  semantics. 

We  present  our  design  by  first  describing  the  stream-based  FRP 
implementation  in  Haskell.  Then  we  state  some  simple,  informal 
observations  about  the  stream-based  implementation.  In  the  next 

4In  fact,  there  have  been  multiple  independent  stream-based  implementations  of 
FRP.  In  this  paper,  “the  stream-based  implementation  (of  FRP)”  refers  only  to  the 
implementation  by  Hudak  [9]. 

5Namcly,  that  the  implementation  is  unable  to  detect  instantaneous  predicate 
events.  This  issue  is  discussed  more  fully  in  section  6. 


section,  we  will  use  these  observations  to  derive  an  event-driven 
implementation  of  FRP  in  Java. 

3.1  Stream-Based  Implementation  of  FRP 

The  stream-based  implementation  defines  FRP  Behaviors  and 
Events  as  stream  transformers  (in  the  signal  processing  sense)  with 
the  following  Haskell  definitions6: 

type  Behavior  a  =  [(Maybe  UA,Time)]  ->  [a] 
type  Event  a  =  [(Maybe  UA,Time)]  ->  [Maybe  a] 

Here  ua  is  a  type  that  represents  a  user  action  as  obtained  from  the 
Operating  System,  such  as  a  mouse  event  or  a  key  being  pressed. 
The  type  Maybe  ua  is  a  possible  user  action;  its  value  is  either 
Nothing  or  Just  x,  where  x  is  some  ua.  Another  important  detail 
is  that  because  Haskell  uses  lazy  evaluation,  lists  and  streams  have 
exactly  the  same  representation.  Hence,  for  our  purposes,  we  can 
read  [a]  as  “stream  of  a”. 

A  Behavior,  then,  takes  an  input  stream  consisting  of  pairs 
of  possible  user  actions  and  sample  times,  and  produces  an  output 
stream  of  behavior  values.  An  Event  source  takes  the  same  input 
stream  as  a  Behavior,  but  produces  an  output  stream  consisting 
of  possible  event  occurences. 

The  FRP  model  defines  a  set  of  combi nators  (such  as 
switcher,  -=>,  etc.)  for  composing  new  behaviors  and  events 
from  existing  ones.  An  FRP  program  is  an  expression  composed 
from  nested  applications  of  these  combinators  to  other  combina- 
tors  or  to  primitive  behaviors  and  events  provided  by  the  imple¬ 
mentation.  The  stream-based  implementation  (and  all  of  the  other 
Haskell  implementations,  for  that  matter)  implement  these  combi¬ 
nators  directly  as  Haskell  functions.  However,  as  with  all  Haskell 
programs,  Haskell’s  lazy  evaluation  semantics  result  in  the  implicit 
construction  of  a  graph  at  runtime,  where  each  node  in  the  graph 
is  an  FRP  combi nator,  and  each  edge  represents  the  application  of 
that  combinator  to  some  other  Behavior  or  Event.  This  is  illustrated 
in  figure  1. 

This  figure  illustrates  a  stream-based  implementation  of  the 
FRP  model  for  computer  animation7.  The  user  program  is  a  graph 
structure,  the  inputs  to  the  graph  are  streams  of  sample  times  and 
user  actions,  and  the  output  of  the  graph  is  a  stream  of  Pic¬ 
ture  values  (one  for  each  sample  time  fed  as  input).  Because  of 
lazy  evaluation,  control  flow  starts  at  the  outputs,  and  successive 
Picture  values  are  “pulled”  from  the  graph  by  the  application  of 
MapM_  drawPic  on  the  right  to  the  output  of  the  user  program. 
Applying  MapM_  drawPic  to  the  output  stream  forces  the  compu¬ 
tation  of  the  first  Picture  of  the  output  stream  (i.e.  the  head  of 
the  list).  To  compute  this  picture,  the  outermost  combinator  node 
in  the  graph  of  the  user  program  must  compute  a  value.  Typically 
this  will  force  the  computation  of  the  inputs  to  this  outermost  node 
(i.e.  the  combinator  nodes  to  which  this  node  was  applied  when 
defining  the  user  program.) 

Control  flow  proceeds  in  this  way  (from  outputs  to  inputs  of 
each  node)  until  some  combinator  in  the  graph  forces  the  computa¬ 
tion  of  the  next  (Time  ,UserAct  ion)  pair  from  the  input  stream. 
When  this  happens,  the  implementation  will  make  one  blocking 
call  to  the  Operating  System’s  event  loop,  returning  only  when  ei¬ 
ther  a  user  action  event  has  occurred  or  one  sample  interval  has 
passed.  In  either  case,  the  implementation  provides  values  for  the 
heads  of  the  input  streams  of  the  graph,  and  control  flow  works  its 
way  back  through  the  graph  until  the  computation  of  the  current 
Picture  value  is  complete.  The  Picture  value  is  then  rendered  on 

6Up  to  an  isomorphism.  The  actual  types  have  been  massaged  slightly  to  simplify 
the  exposition. 

7Hence  the  type  of  user  program  as  Behavior  Picture. 
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FRP  Implementation 


User  Program 

: : Behavior  Picture 


Figure  1:  Stream-based  implementation  of  FRP 


the  screen  by  drawPic,  MapM_  forces  the  computation  of  the  next 
picture  value  of  the  output  stream,  and  the  whole  process  repeats. 

3.2  Observations 

From  the  preceding  description,  we  can  make  the  following  obser¬ 
vations  about  the  stream-based  implementation: 

1.  FRP  Programs  are  really  directed  graphs  at  runtime*  Each 
node  in  this  graph  corresponds  to  an  FRP  combinator,  and 
each  edge  corresponds  to  an  application  of  the  combinator 
to  some  other  combinator  or  a  primitive  event  or  behavior. 
The  graph  is  constructed  implicitly  as  a  by-product  of  lazy 
evaluation,  and  is  completely  hidden  from  the  user,  but  the 
graph  structure  must  exist  in  some  form  at  runtime  to  provide 
accurate  lazy  evaluation  semantics. 

2.  Sample  times  increase  monotonically.  Each  time  a  new  Pic¬ 
ture  value  is  computed,  it  results  in  reading  the  next  User- 
Action  or  Time  value  from  the  program’s  input  stream, 
which  in  turn  results  in  a  single  pass  through  the  operating 
system’s  event  loop. 

Regardless  of  whether  the  call  to  the  event  loop  returns  a 
UserAction  or  times  out,  the  Time  value  passed  to  the  pro¬ 
gram’s  input  stream  is  greater  than  or  equal  to  the  time  on  the 
input  stream  when  the  previous  frame  was  computed.  Most 
of  the  FRP  combinators  in  the  implementation  depend  on  this 
monotonicity  property. 

3.  Each  FRP  combinator  only  examines  the  head  of  the  input 
stream.  There  are  two  requirements  on  the  implementation 
that  validate  this  observation.  The  first  is  that  FRP  combina¬ 
tors  do  not  retain  any  history  of  previous  (Maybe  ua  ,  Time) 
value  pairs.  If  an  FRP  combinator  did  retain  such  values,  this 
could  lead  to  a  space  leak,  as  described  in  [4]. 

The  second  requirement  is  that  each  combinator  must  pro¬ 
duce  a  value  on  its  output  stream  every  time  a  new  (Maybe 
ua, Time)  value  is  delivered  on  its  input  stream.  This  latter 
requirement  is  necessary  because  each  (Maybe  UA,Time) 
value  demanded  from  the  input  stream  results  in  a  blocking 
call  to  the  operating  system’s  event  loop.  If  any  FRP  com¬ 
binator  demanded  another  value  from  its  input  stream  before 
producing  any  output,  then,  in  the  presence  of  nested  and  re¬ 
cursive  combinators,  this  could  result  in  arbitrarily  long  de¬ 
lays  before  the  program  produced  any  output. 

sThis  is  true  of  any  Haskell  program,  but  is  critical  to  understanding  the  sequence 
of  actions  in  the  stream-based  FRP  implementation. 


4.  The  stream-based  implementation  performs  sampling  even 
for  purely  event-driven  applications.  Consider  the  following 
Behavior: 

mycolor  : :  Behavior  Color 

mycolor  =  red  'until'  (lbp  ->>  blue) 

This  defines  a  behavior  (of  type  Color)  that  will  be  red  un¬ 
til  the  left  mouse  button  is  pressed,  and  then  will  change  to 
blue.  Behaviors  such  as  this  one  (common  in  graphical  user 
interfaces)  are  purely  event-driven  in  the  sense  that,  while 
their  value  changes  over  time,  their  value  depends  solely  on 
user  input  events,  not  on  the  sample  time.  Contrast  this  with 
a  definition  such  as: 

wiggle  : :  Behavior  float 
wiggle  =  sin  time 

which  is  an  example  of  a  time-dependent  behavior. 

In  the  stream-based  implementation  of  FRP,  the  implementa¬ 
tion  performs  sampling  regardless  of  whether  or  not  the  FRP 
program  actually  has  any  time-dependent  behaviors.  That 
is,  even  if  the  user  program  is  purely  event-driven,  the  im¬ 
plementation  will  Still  produce  a  new  (Maybe  UA,Time) 
pair  on  the  program’s  input  stream  every  sample  interval,  and 
compute  a  value  to  place  on  the  output  stream  of  every  combi¬ 
nator  in  the  graph.  We  refer  to  this  as  the  “sampling  overhead” 
of  the  stream-based  implementation. 

4  Implementing  FRP  in  Java 

In  this  section,  we  present  our  implementation  of  FRP  in  Java.  We 
use  the  observations  about  the  stream-based  implementation  pre¬ 
sented  in  the  previous  section  to  justify  the  validity  of  our  design. 
Since  the  derivation  is  based  on  the  observations  about  the  stream- 
based  implementation,  and  since  the  stream-based  implementation 
has  been  shown  to  implement  the  formal  semantics  of  FRP,  we 
claim  that  our  event-driven  design  is  also  faithful  to  the  formal  se¬ 
mantics.  With  a  suitable  framework  for  formalizing  the  observa¬ 
tions  in  the  last  section,  and  for  describing  the  Java  constructs  used 
in  our  implementation,  it  should  be  possible  to  give  an  operational 
semantics  of  FrappS  in  terms  of  the  stream-based  implementation 
of  FRP  in  Haskell. 

4.1  Behaviors 

Recall  the  first  three  observations  of  section  3.2: 

1.  FRP  Programs  are  really  directed  graphs  at  runtime. 
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public  interface  Behavior  { 

/**  Accessor  to  read  the  current  value  of  this  Behavior 
*/ 

public  Object  getValueO; 

/**  Add  a  PropertyChangeListener  to  be  notified  when 
*  the  value  of  this  Behavior  changes. 

*/ 

public  void 

addPropertyChangeListener (PropertyChangeListener  1)  ; 

/**  Remove  a  PropertyChangeListener  from  the  list  of  listeners. 
*/ 

public  void 

removePropertyChangeListener (PropertyChangeListener  1)  ; 

} 


Figure  2:  Java  encoding  of  Behaviors 


2.  Sample  times  increase  monotonically. 

3.  Each  FRP  combinator  only  examines  the  head  of  the  input 
stream. 

Since  Java  does  not  have  lazy  evaluation,  we  must  construct 
the  graph  of  combinator  applications  explicitly.  We  achieve  this  by 
defining  a  Java  class  for  each  FRP  combinator.  Each  node  in  the 
combinator  graph  is  represented  by  an  object  instance  at  runtime, 
and  each  edge  is  represented  by  a  field  with  a  reference  to  another 
object. 

What  operations  must  each  node  in  the  combinator  graph  sup¬ 
port?  We  can  combine  observations  (2)  and  (3)  above  to  reach  a 
somewhat  surprising  conclusion: 

•  Each  Behavior  node  in  the  FRP  combinator  graph  can  be 
modelled  as  an  object  that  has  just  one  operation:  get  the 
value  of  the  Behavior  at  the  current  time. 

We  can  implement  this  model  by  defining  a  Behavior  as  a  Java 
Bean  with  a  single,  readable  property  (called  “value”)-  The  Behav¬ 
ior’s  value  at  the  current  time  is  obtained  by  reading  the  Behavior’s 
“value”  property. 

Individual  Behavior  objects  might  be  connected  as  inputs  to 
other  nodes  in  the  combinator  graph,  and  those  nodes  will  need 
to  be  informed  when  a  Behavior’s  value  has  changed.  Hence,  we 
make  value  a  bound  property,  so  that  other  nodes  can  register  for 
a  Property  Change  Event  when  the  value  of  the  Behavior  changes. 
Our  implementation  uses  such  events  to  propagate  behavior  values 
through  the  system. 

This  leads  to  the  Java  encoding  illustrated  in  figure  2.  While 
the  syntax  is  somewhat  verbose,  this  can  be  read  simply  as  “Every 
Behavior  is  a  Bean  that  provides  a  bound  property  named  value!' 

An  implementation  of  the  Behavior  interface  supports  reg¬ 
istration  of  listeners ,  as  required  of  bound  properties.  All  output 
connections  for  a  node  are  stored  in  this  listener  list.  If  an  FRP 
combinator  class  uses  a  Behavior  as  one  of  its  inputs,  the  com¬ 
binator  class  must  implement  the  PropertyChangeListener  in¬ 
terface  in  order  to  be  notified  of  changes  in  its  input  behavior.  We 
will  see  an  example  of  this  shortly. 

Since  the  Haskell  definition  of  Behavior  is  a  polymorphic  type, 
we  declare  the  return  type  of  getvalue( )  as  object.  The  value 
returned  must  be  converted  to  an  instance  of  the  appropriate  type 
using  a  cast,  and  the  cast  will  be  checked  at  runtime.  This  is  quite 
inefficient  for  behaviors  of  primitive  types,  since  each  value  of  a 
primitive  type  must  be  wrapped  in  an  instance  of  the  appropriate 
wrapper  class  (  integer,  Float,  etc.)  before  it  can  be  returned 
as  an  object.  To  help  avoid  this  inefficiency,  and  to  provide 


rudimentary  static  type  checking,  we  have  defined  a  set  of  sub¬ 
interfaces  that  specialize  Behavior  at  all  of  the  primitive  types  by 
providing  an  accessor  method  specialized  to  the  primitive  type.  For 
example: 

public  interface  FloatB  extends  Behavior  { 
public  float  getFloatValue ( ) ; 

} 

is  the  specialization  of  Behavior  at  the  primitive  type  float.  If 
a  client  of  the  Behavior  interface  knows  the  type  of  a  Behavior’s 
value  ahead  of  time,  specialized  interfaces  like  FloatB  can  be  used 
instead  of  Behavior  to  avoid  creating  the  intermediary  wrapper 
object  and  the  corresponding  runtime  type  check. 

4.2  Events 

We  implement  FRP  Events  by  mapping  the  FRP  notion  of  “event” 
directly  to  a  Bean  Event  named  FRPEvent.  Frappd  defines  one 
class  and  two  interfaces  for  event  handling,  shown  in  figure  3. 

The  class  FRPEvent  represents  a  single  event  occurence.  It  ex¬ 
tends  java. util  .EventObject,  as  required  by  the  Java  Beans 
specification.  As  defined  here,  the  only  information  carried  with  an 
event  occurence  is  a  reference  to  the  FRPEvent  Source  that  gen¬ 
erated  the  event.  In  the  FRP  model,  however,  each  event  occurence 
may  carry  a  data  value  of  some  type.  We  accomodate  this  by  defin¬ 
ing  a  subclass  of  FRPEvent  called  objectEvent  that  carries  a 
single  value  (of  type  object).  For  convenience,  we  also  define 
several  subclasses  of  ObjectEvent  specialized  at  various  types. 
For  example,  we  define  a  BehaviorEvent  class  for  events  that 
carry  a  Behavior  reference  on  each  occurence. 

The  FRPEvent  Source  interface  is  implemented  by  every  class 
that  generates  FRP  Events.  This  interface  corresponds  directly 
with  the  Haskell  type  Event  a  that  identifies  an  event  source  in 
the  stream-based  implementation.  The  methods  defined  in  fr- 
PEventsource  are  those  prescribed  by  the  Java  Beans  conven¬ 
tions  for  registering  event  listeners.  This  interface  declaration  can 
be  read  as  stating  that  “Every  FRP  Event  Source  is  a  Bean  event 
source  for  the  event  named  FRPEvent  ” 

The  FRPEvent  Listener  interface  is  implemented  by  any 
class  that  wishes  to  be  notified  when  an  FRPEvent  occurs  on  some 
source.  A  listener  is  registered  with  the  event  source  by  passing  a 
reference  to  the  listener  to  the  source’s  addFRPEvent Listener  ( ) 
method.  Then,  at  some  point  later  when  the  event  occurs,  the  event 
source  will  notify  all  registered  listeners  by  invoking  each  listener’s 
eventOccurred  ( )  method,  passing  it  an  FRPEvent  instance  rep¬ 
resenting  the  event  occurence. 
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/**  Class  representing  a  single  event  occurence  */ 
public  class  FRPEvent  extends  EventObject  { 
public  FRPEvent (FRPEventSource  source)  { 

} 

} 

/**  Interface  implemented  by  interested  listeners  */ 
public  interface  FRPEventListener  extends  EventListener  { 

/**  invoked  when  the  given  FRPEvent  has  occured  */ 
public  void  eventOccured {FRPEvent  event); 

} 

/**  Source  of  FRP  events;  provides  methods  for  registering 
*  listeners  to  be  notified  of  occurences. 

*/ 

public  interface  FRPEventSource  { 

public  void  addFRPEventListener (FRPEventListener  listener); 
public  void  removeFRPEventListener (FRPEventListener  listener); 

} 


Figure  3:  Java  Encoding  of  FRP  Events 


4.3  Defining  Combinators 

In  our  implementation,  every  FRP  combinator  is  implemented  as  a 
Java  class.  Each  combinator  class  implements  one  of  the  standard 
FRP  interfaces  (  Behavior  or  FRPEventSource)  appropriate  to 
the  result  type  of  the  combinator.  The  arguments  to  the  combinator 
are  typically  passed  as  arguments  to  the  constructor. 

For  example,  in  Haskell,  we  might  define  an  overPic  com¬ 
binator  for  compositing  two  animations  (of  type  Behavior  Pic¬ 
ture,  or,  more  succinctly,  PictureB)  into  a  single  animation.  In 
Haskell,  this  combinator  would  have  the  following  signature: 

overPic  : :  PictureB  ->  PictureB  ->  PictureB 
In  our  Java  implementation,  we  would  implement  this  as: 

public  class  OverPic 
implements  Behavior, 

PropertyChangeListener  { 
public  OverPic (Behavior  picl, 

Behavior  pic2) 


//  invoked  when  picl  or  pic2  changes: 
public  void  propertyChanged ( . . . )  { 

} 

//  get  the  composition  of  picl  and  pic2 : 
public  Object  getValue ( . . . )  { 

} 

//  not  shown:  addPropertyChangeListener , 

//  removePropertyChangeListener . 

} 

Note  that  OverPic  implements  two  interfaces:  Behavior  (since 
the  combinator  produces  a  Behavior)  and  PropertyChangeLis¬ 
tener.  This  latter  interface,  defined  in  the  Java  Beans  Specifica¬ 
tion,  requires  that  the  object  implement  the  propertyChanged  ( ) 
method.  Implementing  this  interface  allows  OverPic  to  register  it¬ 
self  as  a  PropertyChangeListener  on  picl  and  pic2,  which 
will  invoke  OverPic’s  propertyChanged  ( )  method  when  either 
picture  changes. 

Of  course,  as  noted,  this  encoding  requires  the  programmer  to 
pass  Behaviors  that  carry  values  of  the  appropriate  type  (  Picture) 


to  OverPic.  Otherwise  a  runtime  error  will  result  when  Over¬ 
Pic  attempts  to  cast  the  result  of,  say,  picl .  getValue  ( )  to  type 
Picture. 

4.4  Propagation  of  Event  and  Behavior  Values 

Propagation  of  event  and  behavior  values  in  Frapp6  is  purely  event- 
driven.  To  execute  an  FRP  specification,  a  user  program  simply 
constructs  an  explicit  graph  of  FRP  combinators  ( initialization ), 
and  relinquishes  control  to  the  main  event  loop  in  the  Java  runtime 
library.  When  there  is  input  to  the  application  (for  example,  when 
the  user  presses  a  mouse  button),  the  Java  runtime  will  invoke  an 
event  handler  of  some  object  in  the  Frappd  implementation  that  im¬ 
plements  a  primitive  FRP  event  source  or  behavior.  This  primitive 
event  handler,  in  turn,  will  invoke  the  appropriate  event  handler  of 
each  registered  listener: 

•  For  an  event  source,  each  event  listener  implements  the 
FRPEventListener  interface.  The  listener’s  eventOc¬ 
cured  { )  method  is  invoked  to  propagate  the  event  occurence. 

•  For  a  behavior,  each  event  listener  implements  the  Proper¬ 
tyChangeListener  interface.  The  listener’s  property- 
changed  ( )  method  is  invoked  to  propagate  the  change  in  the 
behavior’s  value. 

Each  registered  listener  for  a  primitive  event  or  behavior  is  an  FRP 
combinator.  The  combinator’s  event  handler  will  compute  any 
changes  to  its  output  and  invoke  an  event  handler  method  on  each 
of  its  registered  listeners.  Propagation  of  events  continues  in  this 
way  until  some  “output”  listener  is  reached. 

(Maybe  have  a  diagram  here??) 

4.5  Where  did  the  Time  Go? 

In  the  stream-based  implementation,  every  Behavior  has  access  to 
an  input  stream  of  user  actions  and  sample  times.  However,  as 
observation  (3)  of  section  3.2  makes  clear,  the  only  time  value  that 
is  actually  accessible  to  a  combinator  from  this  input  stream  is  the 
current  time.  Of  course,  this  could  just  as  easily  be  accessed  from 
the  global  Behavior  time  defined  by  the  FRP  implementation. 

Like  other  FRP  implementations,  Frappg  provides  user  pro¬ 
grams  with  a  Behavior  that  represents  the  current  time: 
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public  class  Animator  { 

public  FloatB  getTimelnstance () ; 

} 


The  behavior  returned  from  getTimelnstance  {)  is  equivalent 
to  the  global  Behavior  time  in  other  Haskell-based  implementa¬ 
tions.  This  primitive  behavior  is  implemented  by  a  software  timer 
(our  implementation  uses  an  instance  of  j  avax .  swing .  Timer  in¬ 
ternally).  The  implementation  maintains  an  internal  floating  point 
value  that  represents  the  current  time  (in  seconds)  since  the  ap¬ 
plication  started.  The  software  timer  causes  an  event  handler  on 
the  time  implementation  to  be  invoked  at  regular  sample  intervals. 
Each  time  this  event  handler  is  invoked  it  updates  its  notion  of  the 
current  time,  and  propagates  a  PropertyChangeEvent  to  all  reg¬ 
istered  listeners. 


Our  treatment  of  time  differs  from  the  previous  Haskell-based 
implementations  in  that  combinators  that  need  access  to  the  time 
instance  must  have  the  time  instance  passed  in  explicitly.  To  illus¬ 
trate  this  difference,  consider,  for  example,  an  integrator  that  im¬ 
plements  a  numerical  approximation  of  the  mathematical  function 
defined  as 


integrator(vyt)  —  /  v(t) 
Jo 


The  stream-based  implementation  (as  well  as  other  Haskell-based 
implementations)  define  a  combinator  integral  with  the  Haskell 
signature: 


integral  : :  FloatB  ->  FloatB 


The  expression  integral  x,  when  applied  to  some  x  (of  type 
FloatB)  yields  another  FloatB  equal  to  int e grat or ( x,  time), 
where  time  is  the  current  time.  That  is,  the  stream-based  imple¬ 
mentation  does  not  require  that  time  be  passed  in  explicitly  to 
integral. 

Our  implementation  also  provides  approximate  numerical  inte¬ 
gration.  However,  we  require  that  the  time  instance  be  passed  in 
explicitly: 

FloatB  x,  time,  ix; 


time  =  animator .getTimelnstance () ; 
ix  =  new  Integral (x, time) ; 


Requiring  that  time  be  passed  explicitly  enables  an  impor¬ 
tant  optimization:  the  implementation  can  eliminate  the  “sam¬ 
pling  overhead”  of  the  stream-based  implementation  described 
in  section  3.  All  combinators  that  are  time  dependent  must 
be  explicitly  passed  the  time  instance  returned  from  Anima¬ 
tor.  getTimelnstance  ( ).  Such  time-dependent  combinators 
will  then  register  to  be  notified  every  time  the  sample  time  changes 
by  calling  the  addPropertyChangeListener  ( )  method  of 
time.  If  an  application  is  purely  event  driven,  then  there  will  be  no 
registered  listeners  on  the  time  instance.  In  this  case,  the  Frappe 
implementation  turns  off  the  software  timer  used  internally,  which 
allows  the  Java  runtime  to  perform  an  indefinite  (i.e.  no  timeout) 
blocking  call  to  the  operating  system’s  event  loop,  putting  the  ap¬ 
plication  to  sleep  until  some  user  action  occurs. 

This  treatment  of  time  has  an  important  effect  on  how  time 
transformations  are  handled  in  Frapp6.  The  Haskell-based  imple¬ 
mentations  of  FRP  provide  a  generalized  time  transformation  com¬ 
binator  for  transformation  of  local  time-frames: 

timeTransform  : :  Behavior  a  ->  TimeB  ->  Behav¬ 
ior  a 

This  could  be  use  to  transform  a  Behavior  without  knowing  the 
time -dependencies  of  the  behavior.  For  example: 

timeTransform  x  (time/ 2) 


produces  a  version  of  x  that  is  slowed  by  a  factor  of  2,  regardless 
of  how  x  is  defined. 

In  Frappe,  it  is  still  possible  to  perform  time  transforms,  al¬ 
beit  in  a  substantially  limited  form.  The  programmer  may  only 
transform  time-dependent  behaviors,  and  must  do  so  by  interpos¬ 
ing  the  appropriate  transformation  between  the  combinator  and  its 
time  source.  So,  for  example,  to  speed  up  an  animation  by  a  factor 
of  two  we  must  replace: 

b  =  new  BouncingBall (time) ; 
with: 

b  =  new  BouncingBall (new  DoubleArg  (time)  )  ; 

where  DoubleArg  represents  some  combinator  that  doubles  its 
argument  behavior. 

Since  our  encoding  of  FRP  events  does  not  explicitly  time 
stamp  each  event,  there  is  no  direct  mechanism  for  applying  time 
transforms  to  event  sources  or  to  behaviors  that  are  driven  by  event 
sources  other  than  time. 

4.6  Connecting  to  Java  Beans 

The  stream-based  implementation  of  FRP  defines  a  fixed  set  of 
“primitive”  behaviors  and  events  that  are  available  to  user  pro¬ 
grams.  These  primitives  typically  represent  I/O  connections  avail¬ 
able  to  the  application.  For  example,  mouse  is  a  primitive  behavior 
corresponding  to  the  current  mouse  position,  and  lbp  is  a  primitive 
event  source  whose  event  occurences  correspond  to  the  left  mouse 
button  being  pressed.  Because  this  set  of  primitives  is  implemented 
by  interfacing  directly  with  the  Operating  System,  adding  a  new 
kind  of  I/O  connection  to  the  FRP  implementation  requires  source- 
level  changes  to  the  FRP  implementation. 

In  contrast,  Frapp6  allows  any  Java  Bean  to  be  used  as  a  source 
or  sink  for  the  FRP  combinators.  Recall  from  section  4. 1  that  a 
Behavior  is  just  a  Java  Bean  with  a  bound  property  named  value, 
of  type  object.  We  can  treat  any  bound  property  of  any  Java 
Bean  as  a  Behavior  simply  by  constructing  a  Behavior  that  changes 
whenever  the  named  property  of  the  Bean  changes.  We  provide  a 
PropertyObserver  class  for  this  purpose: 

public  class  PropertyObserver 
implements  Behavior, 

PropertyChangeListener  { 

public  PropertyObserver (Object  target, 

String  propName)  { 


} 


> 

PropertyObserver  uses  reflection  on  the  target  object  to  obtain 
Method  objects  that  represent  the  target’s  addPropertyChange¬ 
Listener  ()  and  getpropName  ( )  methods.  The  former  is  used 
in  the  constructor  of  PropertyObserver  so  that  the  observer  in¬ 
stance  will  be  notified  when  the  target  property  changes,  and  can 
propagate  the  change  to  its  registered  listeners.  The  latter  is  used  in 
the  implementation  of  getValueO  in  PropertyObserver,  so 
that  all  invocations  of  getvalue  ( )  on  the  observer  are  forwarded 
to  the  appropriate  accessor  method  of  the  named  property  on  the 
target  object. 

On  the  output  side,  we  have  defined  a  similar  utility  class  for 
connecting  a  Behavior  to  a  writable  bean  property: 
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public  class  BehaviorConnector 

implements  PropertyChangeListener  { 

BehaviorConnector (Behavior  src, 

Object  target, 

String  propName)  { 

} 

} 

A  BehaviorConnector  registers  itself  as  a  PropertyChangeLis¬ 
tener  on  the  source  behavior  src,  and  uses  reflection  to  look  up 
the  write  method  for  the  property  name  propName  on  the  Bean 
target.  Every  time  the  source  behavior  changes,  the  Behavior¬ 
Connector  instance  obtains  the  value  of  src  and  uses  the  write 
method  to  set  the  value  of  the  named  property  of  target. 

5  Current  Status 

We  have  working  implementations  of  all  of  the  core  combinators 
given  in  [12],  using  the  encoding  of  behaviors  and  events  presented 
in  the  preceding  section.  For  the  most  part,  the  implementation 
of  these  combinators  is  a  straightforward  translation  of  the  formal 
definition  into  the  Java  language  using  the  types  and  propagation 
model  presented  here.  The  code  for  a  prototypical  example  combi- 
nator  (  Switcher)  is  given  in  Appendix  A. 

We  have  tested  our  implementation  by  rewriting  many  of  the 
examples  from  [12]  in  Java.  The  code  for  a  typical  example  is 
given  in  Appendix  B.  Our  experience  thus  far  is  that  the  library 
is  quite  easy  to  use,  but  (unsurprisingly)  the  syntax  for  composing 
FRP  specifications  is  exceedingly  verbose  compared  to  the  embed¬ 
ding  of  FRP  in  Haskell.  However,  since  we  plan  to  use  Frappd  pri¬ 
marily  as  the  back-end  for  a  higher-level  visual  composition  tool, 
this  syntactic  overhead  is  not  too  much  of  a  concern. 

6  Limitations 

Because  Java  lacks  a  polymorphic  type  system,  our  implementa¬ 
tion  of  FRP  is  not  statically  type-safe.  Since  we  plan  to  use  our 
implementation  primarily  as  a  compilation  target  for  some  other 
high-level  tool,  this  is  not  too  much  of  a  concern;  we  expect  tools 
that  generate  Frapp6  combinator  graphs  to  be  aware  of  the  poly¬ 
morphic  nature  of  the  FRP  model,  and  to  only  generate  combinator 
graphs  that  will  not  have  type  errors  at  runtime.  Nevertheless,  it 
would  be  an  interesting  excercise  to  rewrite  Frappd;  using  GJ  [1]. 

Frapp6  assumes  that  event  processing  is  single-threaded  and 
synchronous.  That  is,  all  primitive  Java  Beans  events  used  as 
event  or  behavior  sources  for  Frapp6  must  be  fired  from  the  sys¬ 
tem’s  event  dispatching  thread,  and  each  event  must  completely 
propagate  through  the  FRP  combinator  graph  before  the  next  event 
is  handled.  This  single-threaded,  synchronous  event  processing 
model  is  also  required  by  Java  Swing,  and  Frapp6  does  not  im¬ 
pose  any  further  restrictions  than  those  already  required  for  event 
handling  in  Swing. 

Like  the  stream-based  implementation  from  which  it  derives, 
our  implementation  of  FRP  is  unable  to  detect  instantaneous  pred¬ 
icate  events.  An  instantaneous  predicate  event  is  one  that  happens 
only  at  some  specific  instantaneous  point  in  time.  For  example: 

sharp  : :  Event  { ) 
sharp  =  when  (time==*l) 

is  only  true  instantaneously  at  time=l.  An  event  such  as  sharp  can 
not  be  detected  simply  by  monotonic  sampling;  accurate  detection 
of  predicate  events  requires  interval  analysis ,  as  discussed  in  [5, 4]. 


In  many  ways,  the  inability  to  detect  instantaneous  predicate  events 
is  similar  to  the  problem  of  comparing  two  floating  point  numbers 
for  equality  using  ==,  lifted  to  the  time  domain. 

Finally,  as  discussed  in  section  4.5,  Frapp6  only  provides  an  ex¬ 
tremely  limited  form  of  time  transformation,  and  this  limited  form 
of  time  transformation  violates  the  principle  of  temporal  modular¬ 
ity  proposed  for  Fran  [5].  While  time  transform  is  undoubtedly  use¬ 
ful  for  the  specific  domain  of  computer  animation,  it  is  less  clear 
how  useful  generalized  time  transforms  are  when  using  FRP  for 
other  problem  domains  (such  as  graphical  user  interfaces). 

We  feel  that  there  has  simply  not  been  enough  experience  using 
FRP  to  write  real  applications  to  know  how  significant  these  latter 
two  limitations  are  in  practice. 

7  Related  Work 

Elliot  [4]  has  done  much  of  the  pioneering  work  on  implemen¬ 
tations  of  the  FRP  model  in  Haskell,  and  reported  on  the  design 
tradeoffs  of  various  implementation  strategies.  Hudak  [9]  provides 
a  completely  annotated  description  of  a  stream-based  implementa¬ 
tion  of  FRP  from  which  our  implementation  is  derived. 

Recent  work  in  the  functional  programming  community  has 
produced  ways  to  make  component  objects  and  library  code  writ¬ 
ten  in  imperative  languages  available  from  Haskell  [7,  6,  10].  Our 
work  and  this  previous  work  share  the  common  goal  of  providing 
programmers  with  a  declarative  model  for  connecting  component 
objects  written  in  imperative  languages.  However,  our  approach 
can  be  viewed  as  the  “inverse”  of  these  efforts:  instead  of  embed¬ 
ding  calls  to  component  objects  written  in  an  imperative  language 
into  a  declarative  programming  model,  Frapp6  takes  a  declarative 
programming  model  and  embeds  it  in  an  imperative  language  that 
supports  component  objects. 

Elliot’s  work  on  declarative  event-oriented  programming  [3] 
showed  that  FRP’s  event  model  (implemented  in  Fran)  could  be 
used  to  compose  interactive  event-driven  user  interfaces  in  a  declar¬ 
ative  style,  and  compared  this  to  the  conventional  imperative  ap¬ 
proaches  for  programming  user  interfaces.  FranTk  [17]  is  a  com¬ 
plete  binding  of  the  FRP  programming  model  to  the  Tk  user  inter¬ 
face  toolkit.  FranTk  demonstrates  the  viability  of  using  FRP  for 
user  interfaces,  and  inspired  us  to  explore  how  we  might  adapt  the 
FRP  model  for  use  with  the  Java  Swing  toolkit. 

8  Conclusions  and  Future  Work 

We  have  presented  an  implementation  of  FRP  in  the  Java  program¬ 
ming  language.  The  most  significant  aspect  of  our  implementa¬ 
tion  is  that  it  is  based  on  a  close  correspondence  between  the  FRP 
event/behavior  model  and  the  Java  Beans  event/property  model. 
Our  implementation  imposes  some  limitations  on  the  FRP  model, 
but  preserves  FRP’s  declarative  nature  and  continuous  model  of 
time. 

Our  motivation  for  implementing  FrappS  was  to  make  the  rich 
FRP  model  available  to  Java  programmers  and,  in  particular,  to 
IDE  implementers.  We  believe  that,  with  a  suitable  visual  nota¬ 
tion,  it  should  be  possible  to  substantially  improve  on  existing  user 
interface  builder  tools  included  in  most  IDEs.  We  are  currently  de¬ 
veloping  a  new  visual  application  builder  tool  on  top  of  Frapp6  to 
explore  this  hypothesis.  This  tool  allows  the  user  to  compose  entire 
applications  (not  just  user  interface  layout)  in  a  visual,  declarative, 
direct  manipulation  style,  by  connecting  individual  user  interface 
components  through  a  diagrammatic  representation  of  FRP  combi¬ 
nators.  The  tool  generates  Java  code  to  instantiate  the  user  interface 
components  and  the  Frapp6  objects  connecting  those  components. 
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As  stated  in  section  6,  our  current  implementation  of  Frapp£ 
imposes  some  limitations  on  the  FRP  model.  An  interesting  area 
for  future  research  will  be  examination  of  whether  these  limitations 
can  be  removed  in  the  Java  implementation. 

One  of  the  unique  aspects  of  Frappd  is  its  ability  to  use  Java 
Beans  components  as  sources  or  sinks  for  FRP  combinators.  In 
principle  there  is  no  reason  why  this  features  needs  to  be  limited  to 
our  Java  implementation  of  FRP.  It  would  be  interesting  to  explore 
adding  a  similar  feature  to  one  of  the  Haskell-based  implementa¬ 
tions  of  FRP  using  COM  objects  as  components. 
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A  Implementation  of  Switcher 


j  *  * 

*  Switcher  is  the  fundamental  combinator  for  converting  an  Event  into  a 

*  Behavior.  Switcher  takes  a  Behavior  b  and  a  BehaviorEvent  e,  and 

*  produces  a  new  behavior.  The  new  behavior  initially  folows  b.  But  on 

*  every  event  occurence,  the  switcher  'switches'  to  following  the 

*  behavior  carried  in  e. 

*/ 

public  class  Switcher 

implements  FRPEventListener ,  Behavior,  PropertyChangeListener  { 

/**  behavior  we  are  watching:  */ 
private  Behavior  target  =  null; 

/**  Delegate  who  handles  listener  lists:  */ 

PropertyChangeSupport  listenerManager; 

/*  * 

*  Construct  a  new  switcher  from  the  given  behavior  and  Event  source. 

*  ©param  behavior  Behavior  to  follow  initially 

*  ©param  source  FRPEventSource .  This  Event  source  should  produce 

*  BehaviorEvent ' s  on  each  occurence. 

*/ 

public  Switcher (Behavior  behavior, 

FRPEventSource  source)  { 

listenerManager  =  new  PropertyChangeSupport (this) ; 

setTarget (behavior) ; 

source . addFRPEventListener (this) ; 

} 

/**  Accessor  to  read  the  current  value  of  this  Behavior.  *. 
public  Object  getValueO  { 

//  just  forward  to  behavior  we  are  observing: 
return  target . getValue ( ) ; 

} 

/**  invoked  whenever  the  target  property  changes:  */ 
public  void  propertyChange ( PropertyChangeEvent  e)  { 

//  propagate  change  from  target  property  by  notifying 
//  all  registered  listeners: 
listenerManager . f irePropertyChange ( "value" , 

e .getOldValue ( ) , 
e . getNewValue ( ) ) ; 

} 

/**  invoked  when  event  occurs  on  event  source  */ 
public  void  eventOccured (FRPEvent  event)  { 

BehaviorEvent  be  =  (BehaviorEvent)  event; 

//  switch  behavior  being  observed  to  behavior  carried  in 
//  event  occurence. 
setTarget (be . getBehavior ( ) ) ; 

} 

/**  Set  the  target  behavior  to  observe.  We  first  de-register  with 

*  the  current  target,  and  then  register  with  the  new  target. 

*/ 

protected  void  setTarget (Behavior  newTarget)  { 
if  ( target ! =null)  { 

target . removePropertyChangeListener (this) ; 
listenerManager . f irePropertyChange ( "value" , 

target .getValue ( ) , 
newTarget . getValue ( ) ) ; 


target  =  newTarget; 

target . addPropertyChangeListener ( this ) ; 

} 

//  omitted:  addPropertyChangeListener,  removePropertyChangeListener 


Figure  4:  Typical  FRP  Combinator  implementation 
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B  Example  Application  Using  Frappe 


!  *  * 

*  Display  a  circle  that  changes  color  from  red  to  blue  depending  on  which 

*  mouse  button  is  pressed. 

*/ 

public  class  FranTest5  { 

protected  CircleBean  circle; 
protected  FranFrame  frame; 

FranTestSO  { 

frame  =  new  FranFrame () ; 

Franimator  franimator  =  frame .getFranimator () ; 

Time  time  =  franimator .getTimelnstance () ; 

try  { 

FRPEventSource  lbpEvent Source  = 

FRPUtilities .makeFRPEvent { franimator, 

" f ranMouse" , 

" lbp " ) ; 

FRPEventSource  lbpWithRed  =  new  EventBind ( lbpEvent Source, 

new  ConstB (Color . red) ) ; 


FRPEventSource  rbp Event Source  - 

FRPUtilities .makeFRPEvent { franimator, 

" f ranMouse" , 

" rbp " ) ; 

FRPEventSource  rbpWithBlue  =  new  EventBind (rbpEventSource, 

new  ConstB (Color .blue) ) ; 

//  now  merge  the  two  events  streams: 

FRPEventSource  mouseColorEvents  =  new  Even tMerge ( lbpWithRed, 

rbpWithBlue) ; 

//  create  a  circle  at  the  origin  with  radius  50: 
circle  =  new  CircleBean (0 ,  0,  50); 

//  Shapelmage  is  a  Bean  that  renders  an  image  in  a 
//  target  JComponent  whenever  its  "shape"  property  changes. 
Shapelmage  renderer  =  new  Shapelmage ( 400 ,  400,  franimator); 

//  connect  circle  property  to  Tenderer's  shape  property: 

Behavior  circleB  =  new  PropertyObserver (circle, "shape" ) ; 
new  BehaviorConnector (circleB,  renderer,  "shape"); 

Behavior  colorB  =  new  Switcher(new  ConstB ( Color .blue) , 

mouseColorEvents) ; 

//  connect  colorB  to  Tenderer's  "fillColor"  property: 
new  BehaviorConnector (colorB ,  renderer,  "fillColor"); 

//  finally,  obtain  a  Behavior  from  renderer,  and  set  this 
//  as  the  ImageB  to  be  rendered: 

Behavior  imgB  = 

FRPUtilities .makeBehavior (renderer ,  "image") ; 
franimator . set ImageB ( imgB) ; 

}  catch  (Exception  e)  { 

System. err .println ( "Exception  connecting  behaviors  to  properties:") 
e . printStackTrace ( ) ; 


//  and  start  the  animation: 
frame . start ( ) ; 

} 

public  static  void  main (String  args [ ] )  { 
FranTest5  ftest  =  new  FranTest5(); 

} 


Figure  5:  Example  application  using  Frappe 
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